Content Server Install Guide 6.5 SP2

EMC ® Documentum ®
Content Server
Version 6.5 SP2
Installation Guide
300-007-195–A02
EMC Corporation
Corporate Headquarters:
Hopkinton, MA 01748-9103
1-508-435-1000
www.EMC.com
Copyright © 1992- 2009 EMC Corporation. All rights reserved.
Published June 2009
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.
All other trademarks used herein are the property of their respective owners.
Table of Contents
Preface ................................................................................................................................ 11
Chapter 1 Planning for Content Server Installation ..................................................... 13
Content Server and repository overview ............................................................ 13
Content Server installation models .................................................................... 14
Basic installation model ................................................................................ 15
Single-repository model with content stored at primary site ............................ 16
Single-repository distributed model with content in a distributed
storage area .................................................................................................. 18
Multirepository distributed model by using object replication ......................... 19
Multirepository distributed model working as a federation ............................. 20
Configuration decisions .................................................................................... 21
Location for installing the relational database ................................................. 21
Username Content Server will use to connect to the database .......................... 22
Size of repository to create ............................................................................ 22
Location for storing the content files .............................................................. 22
Name and ID to assign to the repository ........................................................ 23
Connection brokers to which to project Content Server information ................. 23
Permit or require secure SSL connections ....................................................... 24
Authenticate users ........................................................................................ 24
Ports to reserve for Content Server use ........................................................... 25
Repository to use as the global registry .......................................................... 25
Extended services products to license ............................................................ 26
Chapter 2 Preparing the Host for Content Server Installation ...................................... 29

Host preparation checklist ................................................................................ 29
Hardware and network environment requirements ............................................ 31
Internationalization settings .............................................................................. 32
Server host code page ................................................................................... 32
Firewalls .......................................................................................................... 32
Setting up user accounts ................................................................................... 33
Setting up the installation owner account ....................................................... 33
Installation owner account naming requirements ........................................ 33
Required rights for an installation owner account ....................................... 33
The installation owner in SQL Server repositories ................................... 34
Setting up the repository owner account ........................................................ 34
Repository owner account naming requirements ........................................ 34
Setting up repository user accounts ............................................................... 35
Preparing UNIX and Linux hosts ....................................................................... 35
Shared memory and semaphore requirements ................................................ 35
XWindows requirement ................................................................................ 35
The /tmp directory ........................................................................................ 36
Root user password ...................................................................................... 36
Setting Documentum environment variables .................................................. 36
Setting up the services file ............................................................................. 36
EMC Documentum Content Server Version 6.5, SP2 Installation Guide 3

Table of Contents
Preparing Windows hosts ................................................................................. 37

Setting the PATH Environment Variable ......................................................... 38
Running WDK Applications on the Content Server Host ................................. 38
Restricted Characters .................................................................................... 38
Regional Settings .......................................................................................... 38
SMTP Server on Windows ............................................................................. 39
Chapter 3 Preparing the Database for Content Server Installation .............................. 41

Database preparation checklists ......................................................................... 41
Requirements for all databases .......................................................................... 44
Database code page ...................................................................................... 44
Database versions ......................................................................................... 45
Database service on Windows ....................................................................... 45
Repository owner account ............................................................................. 45
Database administrator account..................................................................... 46
Oracle requirements ......................................................................................... 47
Entries in tnsnames.ora file............................................................................ 47
Oracle repository sizes .................................................................................. 48
SQL Server requirements .................................................................................. 48
Configuring an ODBC Data Source for SQL Server ......................................... 48
SQL Server repository sizes ........................................................................... 49
Sybase requirements ......................................................................................... 49
Sybase repository sizes ................................................................................. 50
DB2 requirements ............................................................................................. 50
DB2 performance wizard requirements .......................................................... 52
Running multiple Content Servers on the DB2 host ......................................... 52
DB2 repository sizes ..................................................................................... 52
Chapter 4 Installing Content Server ............................................................................. 55

Installation and configuration checklist .............................................................. 55
Installing Content Server software on a UNIX or Linux host ................................ 57
Installing Content Server software on a Windows host ........................................ 60
Configuring Content Server and the repository on a UNIX or Linux host ............. 63
Running the administrative tool script manually ................................................ 68
Configuring Content Server and the repository on a Windows host ..................... 68
Reviewing the Content Server installation logs ................................................... 74
Chapter 5 Completing the Installation ......................................................................... 75

Running dm_root_task manually on UNIX or Linux hosts .................................. 75
Changing the default passphrase ....................................................................... 76
Binding Content Server to a network card .......................................................... 76
Configuring JBoss application servers for SSL ..................................................... 76
Changing the installation owner account............................................................ 77
Backing up key store files .................................................................................. 79
Starting Content Server and the connection broker.............................................. 79
Adding users and groups to a repository ........................................................... 80
Enabling jobs after installation ........................................................................... 80
Enabling the purge audit job ......................................................................... 80
Creating additional repositories or connection brokers ........................................ 81
4 EMC Documentum Content Server Version 6.5, SP2 Installation Guide

Table of Contents
Chapter 6 Upgrading Content Server ........................................................................... 83

Upgrade checklist ............................................................................................. 83
Migrating the database to UTF–8 ................................................................... 86
The database_refresh_interval key ................................................................. 86
Oracle optimization setting ........................................................................... 86
Completing workflows before an upgrade ..................................................... 86
Upgrading sequence considerations ............................................................... 87
Upgrading from 5.x ...................................................................................... 87
Upgrading the Content Server software ............................................................. 88
Using the update statistics tool .......................................................................... 91
Arguments ................................................................................................... 91
Adding descriptors to a global registry .............................................................. 93
Chapter 7 Uninstalling Content Server ........................................................................ 95

Order of uninstalling components ..................................................................... 95
Deleting a repository ........................................................................................ 96
Deleting a connection broker ............................................................................. 97
Uninstalling the Content Server software ........................................................... 97
Chapter 8 Installing Documentum Messaging Services ............................................... 99

Configuration requirements .............................................................................. 99
The dms.properties file ................................................................................... 100
File administration ..................................................................................... 100
Changing the JMX user password ................................................................ 100
Specifying the cleanup interval for expired messages ........................................ 100
Preinstallation requirements............................................................................ 101
Installing DMS ............................................................................................... 101
Uninstalling DMS ........................................................................................... 104
On Windows hosts ..................................................................................... 104
On UNIX and Linux hosts ........................................................................... 105
Starting and stopping DMS ............................................................................. 105
On Windows hosts ..................................................................................... 105
On UNIX and Linux hosts ........................................................................... 106
Chapter 9 Installing Remote Content-File Servers in Distributed or

Load-Balanced Configurations .................................................................. 107
Installing and configuring the content-file server .............................................. 108
Upgrading a distributed or load-balanced configuration ................................... 109
Deleting a content-file server ........................................................................... 112
Chapter 10 Installing Content Server with Microsoft Cluster Services ........................ 115
Overview ....................................................................................................... 115
Choosing a configuration ................................................................................ 116
Configuring an active/passive cluster ............................................................... 118
Creating the cluster resource group ............................................................. 118
Installing Content Server software on the nodes ........................................... 119
Configuring Content Server......................................................................... 119
Configuring the connection brokers ............................................................. 124

Table of Contents
Creating additional cluster resources ........................................................... 125

Verifying failover ........................................................................................ 126
Configuring an active/active cluster ................................................................. 127
Creating the first cluster resource group ....................................................... 127
Installing Content Server software on the hosts............................................. 128
Configuring Content Server on the first and second nodes............................. 128
Configuring the second cluster resource group ............................................. 128
Modifying server.ini and dfc.properties ....................................................... 128
Creating the connection broker generic service resource ................................ 129
Creating the Content Server service resource ................................................ 129
Verifying failover ........................................................................................ 130
Upgrading Content Server installed with Cluster Services ................................. 130
Chapter 11 Configuring Multiple Content Servers on a Single Host for a

Particular Repository ................................................................................ 133
Windows hosts ............................................................................................... 133
UNIX hosts .................................................................................................... 135
Chapter 12 Creating a repository copy to test an upgrade .......................................... 137

Creating the test environment ......................................................................... 137
Precopying tasks ............................................................................................ 138
Copying a repository ...................................................................................... 139
Appendix A Required Environment Variables for UNIX and Linux ................................ 143
Appendix B Content Server Installation Directories and Repository
Configuration Scripts ................................................................................ 149
Content Server installation file structure........................................................... 149
_uninst ...................................................................................................... 149
data ........................................................................................................... 150
dba ............................................................................................................ 150
fulltext ....................................................................................................... 150
product ...................................................................................................... 150
server_uninstall .......................................................................................... 150
share ......................................................................................................... 151
Additional directories ................................................................................. 151
Scripts run during installation or upgrade .................................................... 154
Configuration objects .................................................................................. 157
Appendix C Troubleshooting a Content Server Installation .......................................... 159

Identifying the problem and resolution ............................................................ 159
Error during session construction on Solaris-DB2 ......................................... 162
Recovering from a failed repository configuration or upgrade ........................... 162
Enabling tracing in repository configuration scripts .......................................... 163
Recovering from a stalled Content Server upgrade............................................ 163
Appendix D Object Type Categories for Oracle Database Storage ............................... 165
Type categories for tablespace specifications ..................................................... 165
Type categories for extent allocation ................................................................ 166
Object types categorized as large ................................................................. 166
Object types categorized as small ................................................................. 166
Object types categorized as default .............................................................. 167

Table of Contents
Appendix E Defining Oracle or DB2 Database Parameters for Repository

Tables ....................................................................................................... 169
Defining the tablespace ................................................................................... 169
FUNCTION_SPECIFIC_STORAGE ............................................................. 170
TYPE_SPECIFIC_STORAGE ................................................................... 170
Defining the Oracle extent sizes ................................................................... 171
Changing storage parameters for individual object types on Oracle ............... 172
Changing storage parameters for categories of types on Oracle ...................... 172
User-defined object types ............................................................................ 173

Table of Contents
List of Figures
Figure 1. Repository structure ............................................................................................. 14

Figure 2. Basic installation model and component installation order ...................................... 15
Figure 3. BOCS servers at remote sites communicating with the primary site.......................... 17
Figure 4. Remote sites using primary site’s ACS server .......................................................... 18
Figure 5. BOCS servers at remote sites communicating with the primary site.......................... 19
Figure 6. Object replication model ....................................................................................... 20
Figure 7. Federation model ................................................................................................. 20
Figure 8. Active/passive cluster ......................................................................................... 116
Figure 9. Active/active cluster............................................................................................ 117

Table of Contents
List of Tables
Table 1. Host preparation checklist..................................................................................... 29

Table 2. General database installation and configuration checklist ........................................ 41
Table 3. Oracle database installation and configuration checklist .......................................... 42
Table 4. DB2 database installation and configuration checklist ............................................. 43
Table 5. DB2 database installation and configuration checklist ............................................ 43
Table 6. SQL Server database installation and configuration checklist .................................. 43
Table 7. Sybase database installation and configuration checklist ......................................... 44
Table 8. Content Server installation and configuration checklist ........................................... 56
Table 9. Content Server upgrade checklist .......................................................................... 83
Table 10. Update Statistics arguments .................................................................................. 91
Table 11. Parameters required by dm_acs_install.ebs script ................................................. 111
Table 12. Precopying tasks ................................................................................................ 138
Table 13. Required environment variables .......................................................................... 143
Table 14. Subdirectories created during installation ............................................................ 152
Table 15. Repository configuration scripts .......................................................................... 154
Table 16. Troubleshooting checklist .................................................................................... 159

Table of Contents

Preface
Purpose of the manual

This guide contains information and instructions you need to install or upgrade EMC Documentum
Content Server.
If you are installing fulltext indexing, consult the Content Server Fulltext Indexing System Installation
and Administration Guide.
Intended audience
This guide is for system administrators who are responsible for the installation of Content Server.
Revision history
The following revisions have been made to this document:
Revision History
Date Description
June 2009 Initial publication

Preface

Chapter 1
Planning for Content Server Installation
This chapter contains the information you need to plan a Content Server installation or upgrade. This
chapter contains the following topics:
• Content Server and repository overview, page 13
• Content Server installation models , page 14
• Basic installation model, page 15
• Single-repository model with content stored at primary site, page 16
• Single-repository distributed model with content in a distributed storage area, page 18
• Multirepository distributed model by using object replication, page 19
• Multirepository distributed model working as a federation, page 20
• Configuration decisions, page 21
Content Server and repository overview

Content Server software manages the repository and provides content management capabilities. The
repository consists of three main components: a file store containing the content assets, attribute
tables within a relational database, and fulltext indexes. A repository can store its content files in
any of the following:
• Directories on the Content Server host’s file system
• Directories on a remote host to which Content Server has access
• A variety of storage devices including retention type stores, such as EMC Centera and Network
Appliance SnapLock
Content Server coordinates the different forms of data to create the object-based repository. Objects
in the repository are composed of content files (the source file in its native format) and attributes
(also known as metadata or properties), such as document owner, version, and creation date. Metadata
describes the content and the relationships between this content and other objects in the repository.
The repository uses the metadata to organize the content, and users can use metadata to search
for content.
Metadata is stored in tables in a relational database as sets of attributes. A configurable and extensible
set of attributes is stored for each item. A set of attributes can include attributes with a single value,

such as the document’s globally unique identifier. Attributes can also have multiple values, such as
keywords that describe the content.
Figure 1, page 14 shows the basic structure of a repository.
Figure 1. Repository structure
A client application views the repository as a single repository whose implementation details are
irrelevant. Content Server treats the content files and metadata as part of a single entity and handles
updates to the document object as a single transaction: Content Server updates both elements in
concert or updates neither of them. Content Server automatically updates the index entries as well,
ensuring that the three types of data remain synchronized.
Content Server installation models

You can install Content Server and the repository by following different models:
• Basic installation model, page 15
• Single-repository model with content stored at primary site, page 16
• Single-repository distributed model with content in a distributed storage area, page 18
• Multirepository distributed model by using object replication, page 19.
• Multirepository distributed model working as a federation, page 20.

Basic installation model

A basic installation of Content Server consists of several interrelated components:
• File stores, which contain the content files for objects stored in the repository.
• A relational database, which stores metadata about the content files.
• Content Server, which manages the repository.
Content Server itself consists of several distinct process and components, including an application
server reserved for its internal use. The Content Server Administration Guide contains information
about the internal structure of Content Server.
• A connection broker, which provides repository connection information to client applications.
• Documentum Foundation Classes (DFC), which provide the programming interface that client
applications use to communicate with Content Server.
• An SMTP server, which Content Server uses to send tasks and notification messages to user
mailboxes when necessary.
You can install Content Server in different configurations. In the most basic configuration, which is
typically used in development environments, the Content Server, database, and content files all reside
on the same host. In production environments, the Content Server, database, and content files are
almost always installed on different hosts for increased performance.
Figure 2, page 15 shows a basic installation model and the order in which components are installed.
Figure 2. Basic installation model and component installation order
You can install and start a connection broker on the Content Server host as part of the installation
process, or the Content Server can project to one or more connection brokers located on a different
host, thereby making itself available to client applications. Chapter 4, Installing Content Server
provides details on installing and starting a connection broker. When a client application wants to
connect to a repository, the following occurs:
1. The client contacts the connection broker and requests the information it needs to connect with a
Content Server for the requested repository.
2. The connection broker sends back the IP address for the host on which the Content Server resides
and the port number that the Content Server is using.
3. The client application uses that information to open a connection to Content Server.

Client applications communicate with Content Server through its programming interface, DFC.
Content Server also uses an SMTP server to send tasks and notification messages to user mailboxes
when necessary.
The file stores, relational database, and SMTP server must be installed and available before you install
Content Server.Chapter 2, Preparing the Host for Content Server Installation contains information
about the steps to take to prepare to install Content Server. Content Server does not function properly
unless the database is installed correctly. Review the requirements in Chapter 3, Preparing the
Database for Content Server Installation, and ensure that the database installation meets these
requirements. The SMTP server can be on the Content Server host or a remote host. During the
installation procedure, you provide the name or IP address of the computer hosting the SMTP server
so that Content Server can connect to it.
The installation or deployment guide for the application, such as the Webtop Deployment Guide,
contains information about installing client applications.
Single-repository model with content stored at primary

site
In this model, remote users connect through web browsers by using a WDK-based client application.
They access content stored at the primary site through either an ACS or BOCS server.
• An ACS server is dedicated to processing content request. It does not process metadata nor does
it write content to storage.
• A BOCS server is a cache server that communicates with ACS servers. It does not process
metadata nor does it write content to storage.
Two configurations for this model exist:
• The configuration includes a BOCS server, and clients at remote sites use the BOCS server to
access content as shown in Figure 3, page 17:

Figure 3. BOCS servers at remote sites communicating with the primary site
• The configuration includes an ACS server, and clients at remote sites use the ACS server at the
primary site as shown in Figure 4, page 18:

Figure 4. Remote sites using primary site’s ACS server
The Distributed Configuration Guide provides details about this model.
Single-repository distributed model with content in a

distributed storage area
In this model, content is stored in a distributed storage area with multiple component storage areas as
shown in Figure 5, page 19:

Figure 5. BOCS servers at remote sites communicating with the primary site
Multirepository distributed model by using object

replication
In this model, objects consisting of content and metadata are distributed between repositories.
The distribution can occur through user-defined object replication jobs, or internally, when a user
manipulates objects from multiple repositories in one repository session. Figure 6, page 20 illustrates
object replication:

Figure 6. Object replication model
Multirepository distributed model working as a

federation
A federation model consists of multiple repositories where one is the governing repository and the
remainder are member repositories. Placing multiple repositories into a federation model ensures
that users, groups, and ACLs remain synchronized across all repositories in the federation. Figure 7,
page 20 illustrates the federation model:
Figure 7. Federation model

Configuration decisions
When you install Content Server, you are asked to make several configuration decisions. The
remainder of this chapter identifies the decisions you should make before beginning the Content
Server installation procedure. Chapter 3, Preparing the Database for Content Server Installation
and Chapter 4, Installing Content Server provide checklists where you can record your decisions
for reference during the installation procedure.
• Location for installing the relational database, page 21
• Username Content Server will use to connect to the database, page 22
• Size of repository to create, page 22
• Location for storing the content files, page 22
• Name and ID to assign to the repository, page 23
• Connection brokers to which to project Content Server information, page 23
• Permit or require secure SSL connections, page 24
• Ports to reserve for Content Server use, page 25
• Repository to use as the global registry, page 25
• Extended services products to license, page 26
Location for installing the relational database

You can install the relational database that stores repository metadata either locally on the same host
as Content Server or remotely on a separate host running any operating system supported by the
database vendor. For example, Content Server can be installed on a Windows host and use a database
installed on a Solaris host.
In a production environment, the database is almost always installed on a separate host for
performance reasons.
Before you install Content Server — Install the database management system and create a database
in which Content Server will create the repository metadata tables. If you install the database on a
separate host, also install the database client software on the Content Server host.
• For remote database installations, verify that you can connect to the database by using a database
client from the system where you intend to install Content Server.
• For local database installations on a UNIX host, verify that the system path includes the installation
directory for the database. On Windows hosts, the installer updates the system path automatically.
Chapter 3, Preparing the Database for Content Server Installation provides details about installing
the relational database.

Username Content Server will use to connect to the

database
Content Server connects to the database with a user account called the repository owner account. The
repository owner must have a database user account. This database user account must provide
Content Server with access to the database tables underlying the repository.
You can create the repository owner account in the database before installing Content Server, or you
can allow the Content Server configuration program to create the account. The account must have the
appropriate privileges to perform the following tasks:
• Connect to the database
• Create tables, views, and indexes in the database
• Insert records (rows) into the tables
• Drop tables, views, and indexes
Before you install Content Server — Decide whether to create the database account for the
repository yourself or allow the Content Server configuration program to create the account. If you
allow the Content Server configuration program to create the database account, it automatically
grants the account the proper privileges. If you create the account in advance, grant the account the
proper privileges as described in Repository owner account, page 45.
Size of repository to create

During repository configuration, you are asked to choose a repository size. The repository size option
determines the size of the tablespaces within the database, how data and indexes are distributed
within the database, log file sizes, and whether these settings can be configured.
Before you install Content Server — Decide what size of repository to create, based on the projected
amount of content that will be stored in the repository. The details and initial sizes differ depending
on the database vendor. The individual sections for each database vendor in Chapter 3, Preparing the
Database for Content Server Installation provide details.
Location for storing the content files

A repository can store its content files in a variety of storage areas, such as:
• In a directory structure in the Content Server host’s file system or on a remote host
• On a retention type store
• In a relational database as binary large objects (BLOBs), or as data in varchar fields
• In an external storage area, such as a legacy system
Large repositories can have multiple file storage areas, of different types, with defined business rules
that specify which content is stored in which storage areas.

The Content Server installation program creates one file-system storage area, which is used as the
default storage area. After the initial installation, you can add additional storage areas and the
business rules for dividing content between them by using Documentum Administrator. The Content
Server Administration Guide and to the Documentum Administrator User Guide provide information and
instructions about adding additional storage areas.
Before you install Content Server — Choose a location for the default content file storage area,
which the installation program calls the data directory. The data directory can be on the Content Server
host or on another host that Content Server can access over the network. Ensure that the location you
choose for the data directory has sufficient free space for the content files that will be added to it.
The Content Server configuration program creates the data directory on the local host in the directory
Documentum\data unless you provide a different location.
Name and ID to assign to the repository

Each repository requires a unique name and ID of up to 32 characters. The name must consist of
letters, numbers, or underscores (_). The first character must be a letter. The repository name cannot
include spaces or nonalphanumeric characters. All letters and numbers in the name must be ASCII
characters. The repository name “docu” is reserved by EMC Documentum.
The repository ID can be any number from 1 to 16777215 and must not start with a zero. Valid
repository IDs are shipped with the Content Server software. You may also choose your own
repository IDs, provided that each repository has a repository ID that is unique in your network and
conforms to other repository ID requirements. You can request additional repository IDs from EMC
Documentum, which ensures that the ID for each repository is unique. You can submit a request for a
repository ID from the following link on the EMC Powerlink web site http://powerlink.emc.com.
Before you install Content Server — Decide on a repository name and repository ID for the new
repository you will create.
Connection brokers to which to project Content Server

information
When Content Server starts, it automatically broadcasts information about itself to one or more
connection brokers. Each connection broker that receives the broadcast adds the Content Server to
its list of available servers.
Before you install Content Server —

• Record the hostname and port number for each existing connection broker to which you want to
broadcast Content Server connection information.
• Decide whether you need to create additional connection brokers on the Content Server host.
The Content Server configuration program by default creates a connection broker on the Content
Server host and configures the Content Server to broadcast its connection information to that
connection broker. You have the option to create multiple connection brokers if, for example, you
want different brokers for different client applications. If you want Content Server to broadcast its

connection information to existing connection brokers on remote hosts, you can configure this
option after the installation.
• Identify an open port for the new connection broker to listen on. The default port for the default
connection broker is 1489. If you are using the default port number, ensure that the next port
number (1490) is available for use because the connection broker requires that two ports be
reserved. If you create multiple connection brokers on the host, assign a unique port number
to each broker.
Permit or require secure SSL connections

Client applications can connect to Content Server through a standard native port or through a secure
port that uses Secure Sockets Layer (SSL) for encryption. During repository configuration, you are
asked what type of connection clients will use to connect to the repository. The choices are:
• Native — Content Server listens for client connection requests only on ports that are not SSL ports.
Content Server refuses requests for a secure connection.
• Secure — Content Server listens for client connection requests only on a secure SSL port. The
client and Content Server do not use SSL authentication to authenticate each other. However,
the information exchanged between the client and Content Server is encrypted. Content Server
refuses connection requests other than SSL connections.
• Native and secure — Content Server accepts both native and secure connection requests.
Before you install Content Server — Decide what type of client connections to accept.
Authenticate users
User authentication typically occurs when a user attempts to connect to a repository. Content Server
determines whether the user is a valid, active repository user and, if so, authenticates the user name
and password. You can perform user authentication using one of the following methods:
• The default mechanism
The default mechanism authenticates the user against the operating system.
• A custom dm_check_password program
You can create a custom password checking program and set up the servers to call that program
for user authentication. This option is useful if you want to use Windows domain authentication
for UNIX users.
• An LDAP directory server
If you use a directory server, you have the following options:
— Authenticate against the directory server directly, using a secure or a nonsecure connection.
— Authenticate using an LDAP-enabled dm_check_password program.
• A authentication plugin

Authentication plugins provide an alternate way to customize user authentication. EMC

Documentum provides one authentication plugin with Content Server. The plugin allows you to
use the Netegrity SiteMinder Policy Server with Content Server. The plugin supports Web-based
Single Sign-On (SSO) and strong authentication.
• An inline password
A user can be authenticated using an encrypted password that is stored in the user_password
attribute of the user object.
Ports to reserve for Content Server use

Content Server and its components use a number of ports on the host:
• Content Server uses two consecutive port numbers for native client connections and secure client
connections.
— On Windows hosts, set the port numbers by using the Content Server configuration program.
— On UNIX and Linux hosts, set the port numbers in the services file before installing Content
Server. Setting up the services file, page 36 provides details on how to set port numbers in
the services file.
• The application server that Content Server installs listens on one port for administration standard
connections. By default, it uses port 9080.
• The connection broker requires two ports on which to listen. The default connection broker port is
1489. If you are using the default port number, ensure that the next port number (1490) is available
for use because the connection broker requires that two ports be reserved.
Before you install Content Server — Identify available ports to use for Content Server and its
components. Make sure none of the selected ports are being used for other purposes.
Repository to use as the global registry

When an EMC Documentum installation includes multiple repositories, certain installation-wide
elements are shared among all repositories. For example, a distributed configuration uses objects
called network locations which Content Server uses to determine which storage areas are physically
close to which client applications. All repositories share the same network location objects.
To manage these installation-wide elements, each EMC Documentum installation includes a central
repository called the global registry. The global registry is a repository like any other repository, except
that all other repositories connect to it when they need an installation-wide element. When you
install a repository, either identify it as the global registry or designate how to connect to another
global registry repository.
If you have a one-repository implementation, that repository can be both a content repository and a
global registry. If you have a Content Server implementation larger than a departmental one, you
might consider creating a separate repository and designate that repository to be the global registry
only.

The Content Server configuration program enables you to do the following now or later:
• Use the current repository as a global registry.
• Specify a different repository as a global registry.
A global registry user is created in all repositories, regardless of whether the repository is configured
as a global registry.
• If you configure the repository as a global registry, you provide the username and password for
the global registry user and the user state is set to Active.
• If you do not configure the repository as a global registry, a global registry user is created with the
default username dm_bof_registry and the user state is set to Inactive. This user has read access to
objects in a few folders in the System cabinet of the repository only.
Before you install Content Server — Determine whether the repository you create will be a global
registry. If you are installing a single production repository, designate it as a global registry. If the site
has multiple production repositories, designate only one repository as a global registry.
To designate a new repository as a global registry, provide a username and password for the global
registry user in the current repository. Client applications and other repositories will use this login
name and password to connect to the global registry. Record the username and password so that you
can provide it when installing other EMC Documentum products that require global registry access.
The user must have read access to objects in the /System/Modules and /System/NetworkLocations
folders. Do not use the repository owner’s credentials or the installation owner’s credentials.
If you plan to connect to an existing global registry repository, provide the repository name, the
username, and the password of the global registry user in that repository. The current repository is
configured to access the remote global registry repository.
The Content Server configuration program gives you the option to designate the global registry
repository at a later time. If you select this option, use Documentum Administrator to identify the
global registry and enter the appropriate connection information. The Content Server Administration
Guide provides instructions.
Extended services products to license

You can use the Content Server installation program to activate extended service features by entering
the license code for those features. You can activate extended service features either at installation
time by using the installation program or later by using the Content Server configuration program.
The extended feature licenses available from the Content Server installation program are:
• Trusted Content Services provides additional security features, such as encrypted file stores,
in which content files are encrypted and secure socket layer (SSL) communications between
Content Server and DMCL.
• Content Services for EMC Centera and Network Appliance SnapLock adds support for retention
type stores, which provide content storage with guaranteed retention and immutability.
SnapLock is a feature of Filer, a NAS storage system from Network Appliance. You can create a
SnapLock volume in one of two modes: Enterprise and Compliance. The difference between the

two modes is that on the Compliance SnapLock volume, a default (and minimum) retention of
30 years is applied to the content files created in that volume.
• High-Volume Server is an extension of Content Server that supports features implemented to
solve common problems with large content stores. The three broad areas of enhancements that
make up High-Volume Server are:
— Lightweight system objects
— Batch operations and currency scoping
— Database Partitioning
• Content Storage Services enables you to define business rules to govern where content files are
stored.
• Retention Policy Services is a compliance-oriented feature that gives you control over how long
and under what circumstances documents and other objects are retained in a repository.
• Records Manager provides archiving options for business records.
• Physical Records Manager (PRM) enables management of paper assets by providing library
services to reserve, borrow, and return physical objects. PRM also includes barcode management
capability for tracking physical objects.
Trusted Content Services, Content Services for EMC Centera, SnapLock, and High-Volume Server are
installation-wide options, so if you enable them for one repository, their features are available in all
repositories. If you want to enable them after you have already installed Content Server, you need
to run the Content Server installation program again and enable these options. The other extended
services options are enabled in each repository separately.
The Content Server Fundamentals Guide provides details about these products and the features they
enable.
Before you install Content Server — Identify which extended services to enable and obtain the
license code for those services.


Chapter 2
Preparing the Host for Content Server
Installation
Use the information in this chapter to prepare the host on which you plan to install Content Server.
Chapter 3, Preparing the Database for Content Server Installation contains additional information for
preparing the relational database for Content Server.
This chapter contains the following information:
• Hardware and network environment requirements, page 31
• Internationalization settings, page 32
• Setting up user accounts, page 33
• Preparing UNIX and Linux hosts, page 35
Host preparation checklist

Use the following checklist to prepare the host for Content Server installation In the Value column,
enter the required value that you will be prompted for during database installation and configuration.
Table 1. Host preparation checklist
Task Resource Value
Validate the hardware configuration. Content Server Release Notes
Validate the operating system Content Server Release Notes

and operating system-database
configuration combination.
Ensure that the Content Server host’s

video card uses a minimum of 256
colors.

Preparing the Host for Content Server Installation
Task Resource Value
On UNIX and Linux hosts, ensure Shared memory and semaphore

that at least 2 MB of shared memory requirements, page 35
is allocated and that semaphores are
enabled
On Windows, obtain the name of the SMTP hostname:

SMTP host that the Content Server __________
will use for email notifications.
Decide whether to use an LDAP Appendix C, “Using an LDAP

directory server. Directory Server,” in the Content
Server Administration Guide and
Content Server Release Notes
Decide whether to create the Setting up the installation owner

repository owner account and account, page 33, and consult
database storage areas manually or the database administrator.
allow the installer to create them.
Create any necessary accounts and Setting up user accounts, page

groups on the operating system and 33
in the database.
On UNIX and Linux, create any Setting up the services file, page
required services file entries. 36
On UNIX and Linux, optionally Preparing UNIX and Linux

create the installation directory. hosts, page 35
On UNIX and Linux, obtain the root root password

password. __________

Task Resource Value
On Windows, determine the This domain is the default domain name

Windows domain where users are domain if users do not specify __________
authenticated. a Windows domain when they
connect. Choose the domain
with the largest number of users.
Determine the port numbers to The default connection broker port number:
be used by the repository and port is 1489. If you are using __________
connection broker. the default port number, ensure
that the next port number (1490) port number:
is available for use because the __________
connection broker requires that
two ports be reserved.Setting
up the services file, page 36
provides information on port
numbers under UNIX.
Determine the hostname where the hostname:
connection broker will run. __________
Hardware and network environment

requirements
A Content Server installation has the following hardware and network requirements:
• The host for Content Server must meet the hardware and operating system requirements listed
in the Content Server Release Notes.
Depending on which Content Server model you are installing requirements for hardware, disk
space, software, and other environment and system requirements might vary. The Environment
and System Requirements section of the Content Server Release Notes contains the detailed Content
Server installation environment and system requirements.
• The host’s name must use only ASCII characters.
• If you are installing on a host that uses multiple network cards, by default Content Server binds to
the first network card.

Internationalization settings
Content Server runs in the UTF-8 code page. Perform the following tasks before Content Server
installation:
• Install the server host code page.
• Set the code page in the database.
• Set the server host locale.
The server host locale and the server code page do not have to be the same. For example, if
the host code page is set to ISO-8859_1, the host locale would typically be set to a European
language (English, French, German, Italian, Portuguese, or Spanish). If the host locale is set to
French, a client that connects to the Content Server without specifying a client locale is served
French data dictionary labels.
If the host locale is one of the languages supported by EMC Documentum, the data dictionary
information for that locale is loaded. Otherwise, the server defaults to loading the English data
dictionary information. You can load additional sets of data dictionary information by modifying
the data_dictionary.ini file. Installing additional data dictionary information can affect server
performance, and EMC Documentum only supports the languages that are shipped with Content
Server. The Content Server Administration Guide provides information on leading additional data
dictionary information.
— On Windows hosts, the host locale is set in the Regional Settings dialog box.
— On UNIX and Linux hosts, the host locale is set with the LANG environment variable.
Database code page, page 44 contains information about setting the database code page. Content
Server Fundamentals provides complete information on Content Server internationalization.
Server host code page

Content Server may be installed on computers that run the following operating system code pages:
• For U.S. and Western European sites, ISO-8859_1 (Latin-1)
• For Korean sites, EUC-KR
• For Japanese sites that use UNIX, EUC-JP
• For Japanese sites that use Windows, Shift_JIS
• For Chinese sites with locale zh, ms936
• For Russian with locale ru, Windows-1251
Firewalls
All the server-side components of Content Server, such as index server, index agent, and
Documentum Administrator, must be behind a firewall. Only the client side applications, such
as Webtop are supported outside the firewall.

Setting up user accounts

Before installing Content Server, you need to create operating system user accounts for the users
involved in managing and using Content Server and its repository. Set up the user account for
the installation owner and provide the account with the rights necessary to install Content Server.
In most cases, you also need to create operating system user accounts for the repository owner
(corresponding to the database user account that Content Server uses to connect to the repository
database) and for end users who access the repository. The following sections describe the user
roles and the rights they need to have.
Setting up the installation owner account

The installation owner account is used to install Content Server and create a repository. The
installation owner must have an operating system account with appropriate permissions, as described
in Required rights for an installation owner account, page 33. Content Server runs under the
installation owner’s account. The installation owner can perform all administrative or maintenance
tasks associated with the installation or the repository.
The installation owner account may be a local account on the Content Server host or a domain
account in the domain where Content Server is installed. The account must be a member of the
local host’s Administrators group. However, the installation owner account must not be the same
account as the Windows Administrator. On UNIX or Linux, do not use the root account as the
installation owner account.
You can create an operating system account to use exclusively for Content Server installation and
repository maintenance. You can use a single operating system account as installation owner for
multiple Content Server installations on the network.
Installation owner account naming requirements
The installation owner’s username must consist of letters, numbers, dashes (-) or underscores (_). The
first character must be a letter. All characters must be ASCII characters.
The installation owner’s password must consist of letters, numbers, dashes, underscores, or periods.
Note: On Windows hosts, user accounts are not case-sensitive, but Content Server installation fails
if you connect to the host by using the incorrect case in the username. For example, if the account
is set up as JPSmith and you connect as jpsmith, you can log in to the host, but Content Server
installation fails.
Required rights for an installation owner account
The installation owner must have the following user rights:

• Act as part of the operating system
• Create a token object

• Increase quotas
• Log in as a service
• Log in locally
• Replace a process-level token
On a standard Windows system, these rights are automatically inherited with membership in the
local Administrators group. The Setup program checks for these rights and grants them if necessary.
The installation owner must have Full Control permission on the directory into which Content
Server is being installed. The installation owner must also have write permission on the directory
from which the installation program is run. On UNIX or Linux hosts, the installation owner must
have read, write, and execute permission on the /tmp directory.
The installation owner must have an email account on the SMTP mail server.
To support external password validation, set up a group account whose members are the installation
owner, any other Content Server administrators, and repository owners. This will be the group that
owns the external password validation program.
On UNIX and Linux hosts, set several environment variables in the installation owner’s environment.
The Content Server configuration script sets the required variables by default. If you do not use the
Content Server configuration script, you need to manually set the environment variables discussed in
Appendix A, Required Environment Variables for UNIX and Linux.
The installation owner in SQL Server repositories
If SQL Server is installed in a different domain from Content Server, the EMC Documentum
installation owner must be a valid user in the remote domain.
Setting up the repository owner account

The repository owner operating system account is used to connect to the database. The repository
owner owns all objects in the database. Each repository must have a unique repository owner. To
create a new repository you need a repository owner account. If you want to use the option to use an
existing database account when you are creating a new repository, you must have a database user
account established already.
On Windows hosts, set up a Windows account for the repository owner. For installations that use
DB2 databases, the repository owner must be a valid Windows user on the host where the database
is installed. To use Microsoft Cluster Services, the repository owner must have an account in the
domain in which you install the repository.
Repository owner account naming requirements
The repository owner’s username must consist of letters, numbers, dashes (-) or underscores (_). The
first character must be a letter. All characters must be ASCII characters.

The repository owner’s password must consist of letters, numbers, dashes, underscores, or periods.
Setting up repository user accounts

Repository users are the end users in the repository. These users may own documents or other objects
that are stored in a repository, but they have no particular responsibilities for the maintenance of
either the repository or the installation.
On Windows, if the default user authentication is used, each user must have a Windows account
in the domain where Content Server is installed. If LDAP authentication or inline password
authentication is used, this is not a requirement.
On UNIX and Linux, end users who want to run a program whose executable is in $DM_HOME/bin
must have $DM_HOME/bin in their path. For example, application developers who are writing and
testing Docbasic procedures need to have $DM_HOME/bin in their paths.
Preparing UNIX and Linux hosts

If you are running Content Server on UNIX or Linux, create the installation owner’s account and set
variables in the installation owner’s environment before you install. Also create two group accounts
whose member are installation owner and ensure that the shared C library is available.
This section covers these topics, which include requirements in addition to configuring the
installation owner’s environment correctly.
Shared memory and semaphore requirements

Content Server’s shared memory and semaphore requirements are:
• Configure the host with at least two megabytes of shared memory for Content Server.
• Content Server uses a semaphore. Ensure that semaphores are enabled on the host.
XWindows requirement
XWindows must be installed on the UNIX host to run the graphical installation program, and the
xterm program must be in the installation owner’s path. The xterm program may be installed
in various locations depending on the operating system and software packages installed. Some
typical locations are:
• On Solaris, /usr/openwin/bin
• On HP-UX and AIX, /usr/bin/X11
Verify that the xterm program is in one of the preceding paths or in an alternate location and add
that location to the PATH variable.

The /tmp directory

The /tmp directory must have at least 1 GB of available space for a Content Server installation.
Root user password

As part of the Content Server installation procedure, run the dm_root_task script to set the correct
file permissions on a pair of programs required for user authentication (dm_check_password and
dm_change_password). Run the script as the root user with the root user password.
Setting Documentum environment variables

Before you install Content Server on a UNIX or Linux host, set environment variables that identify the
directories into which Content Server will be installed. The variables must be set in the installation
owner’s environment.
You can create the Content Server installation directories before installing the server, or you can allow
the Content Server installation program to create the directories. If you allow the Content Server
installation program to create the directories, ensure that the directory names you provide during the
installation program match the names specified in the environment variables.
The environment variables to set are:
• $DOCUMENTUM
This environment variable corresponds to the Content Server installation directory. On Windows
the default is /Documentum on the current host. The installation owner must have read, write,
and execute permission on the $DOCUMENTUM directory and its subdirectories. For UNIX and
Linux, no default directory exists.
• $DM_HOME
The value of $DM_HOME must be $DOCUMENTUM/product/version_number. version_number, is
the version of Content Server. For example:
$DOCUMENTUM/product/6.5
• $DOCUMENTUM_SHARED
This environment variable sets the directory into which EMC Documentum Foundation Classes
are installed.
The environment variables and installation directories must contain only ASCII characters. The name
of the installation directory must not contain spaces.
Setting up the services file

The services file must contain two entries for each repository running on a host. On UNIX and Linux,
manually create the service name entries in the services file before you install the Content Server.

The repository does not have default service names or default port numbers. The service name you
put in the services file must be the same name you provide during repository configuration, which
is then used to create the server.ini file. The service name for the repository can be the same as
the repository name, but this is not required.
The services file must include entries that designate two consecutive port numbers for use by
Content Server:
• One for native connections.
• One for secure (SSL) connections. Append _s to the name of the repository service for the secure
connections. Repository service names that end with _s are reserved for secure connections.
The default port number on which the connection broker listens is 1489. If you are using the default
port number, ensure the next port number (1490) is also available for use and is not used by any other
item because the connection broker requires that two ports be reserved.
The default connection broker listening port number 1489 is a registered well-known port number. If
the default listening port is used, please make sure the next port number 1490 is available. If you
decide to use a different port number than 1489, you need to create two network service entries
in the system’s service table.
Create the service name entries by using the following format:
service_name port_number/tcp #Put comments here
service_name_s port_number/tcp #Put comments here
If NIS is running, the local services file (/etc/services) is ignored. Place the entries in the NIS services
map. Use the ypwhich command to identify the hostname of the NIS master server, if there is one.
The port numbers can be any unused port numbers greater than 1024. UNIX reserves port numbers
up to 1024 for system use. For example, if the repository service were named “lime”, the services
file entries might be:
lime 1497/tcp # 6.5 Repository native connection
lime_s 1498/tcp # 6.5 Repository secure connection
If the correct services file entries are not present, the installer stops.
If you have multiple repositories on a single host, create a services file entry for each repository.
Ensure that the repositories have different names and port numbers.
Preparing Windows hosts

If you are running Content Server on a Windows host, you must make some configuration changes
in Windows itself and you must ensure that the correct accounts are set up before you install the
server. This section includes the following topics:
• Setting the PATH Environment Variable, page 38
• Running WDK Applications on the Content Server Host, page 38
• Restricted Characters, page 38
• Regional Settings, page 38
• SMTP Server on Windows, page 39

Setting the PATH Environment Variable

On Windows hosts, you must manually add the path to Java to the PATH system environment
variable. If this is not set correctly, custom Java methods executed by the Java method server and
the LDAP and federation jobs do not run correctly on the host.
During Content Server installation, you are asked for a DFC installation directory. This is typically
Drive:\Program Files\Documentum. Installing DFC also installs the JDK. The full path to the Java
installation is typically Drive:\Program Files\Documentum\jdk\131_04\bin, and that is the value to
add to the PATH system environment value.
To modify the PATH environment variable:

1. Right-click My Computer.
2. Select the Advanced tab.
3. Click Environment Variables.
4. In the System Variables section, select PATH and click Edit.
5. Add the value DFC_install_location\jdk\131_04\bin to the path and click Ok.
The DFC installation location is set during server installation. It is typically Drive:\Program
Files\Documentum.
6. Click Ok and close the System Properties dialog box.
Running WDK Applications on the Content Server Host

EMC Documentum Web Development Kit and applications built with WDK (such as Documentum
Administrator) are run with an application server. If you install WDK or a WDK application on the
Content Server host, install and run the application server using an account that is not an EMC
Documentum user. This creates security risks because of trusted login. For more information, refer
to the WDK and Applications Installation Guide.
Restricted Characters
The name of the directory in which Content Server is installed can only contain ASCII characters.
Additionally, do not use the following characters in path names accessed by EMC Documentum
product installers: ! \ / : * ? " < > |
Do not use spaces in the name of the product installation directory. For example, do not use
c:\Documentum Products\ or /Documentum Products as the name of the installation directory.
Regional Settings
Before you install a repository, the Windows Regional Settings must be set to specify a four-digit date.

To specify a four-digit date:

1. Choose Start —>Settings—>Control Panel.
2. Double-click Regional Options.
3. Click the Date tab.
4. Select a date style that includes a four-digit year from the dropdown list.
5. Click Ok.
SMTP Server on Windows

On Windows hosts, Content Server must be able to connect to an SMTP mail server. The SMTP server
can be an SMTP server located on your network or it can be the SMTP server provided with Windows
2000. During the installation or upgrade procedure, you must provide the name or IP address of the
computer hosting the SMTP server.
If a valid SMTP server host name is not available during installation, supply an invalid host name
and the installation will finish. Do not leave the field blank. After installation, add a valid SMTP
server host name to the smtp_server attribute of the server config object. Reinitialize the server after
you update the server config object.


Chapter 3
Preparing the Database for Content
Server Installation
This chapter contains information on configuring the database for Content Server installation. For
details about installing or supporting a database, refer to the database administrator or the database
vendor’s documentation. This chapter contains the following topics:
• Database preparation checklists, page 41
• Requirements for all databases, page 44
• Oracle requirements, page 47
• SQL Server requirements, page 48
• Sybase requirements, page 49
• DB2 requirements, page 50
Database preparation checklists

Use the following checklists to prepare for database installation and configuration. In the Value
column, enter any required values. You will be prompted for these values during database
installation and configuration.
Table 2. General database installation and configuration checklist
Task Resource Value

Validate the operating system and Content Server Release Notes
the combination of operating system
database configuration.
If you are doing a custom Content Database documentation datafile size:
Server installation, determine the __________
datafile size. In a custom installation
you can change the default values.
An express installation uses the
default values.

Preparing the Database for Content Server Installation
Task Resource Value

If you are doing a custom Content Database documentation log file size:
Server installation, determine the __________
log file size. In a custom installation
you can change the default values.
An express installation uses the
default values.
Review the Content Server-specific
information for the database.
Obtain the database administrator “Database administrator database administrator
name and password. account, page 46” and the name:
database administrator __________
database administrator
password:
__________
Install the database instance with Database documentation
the UTF-8 code page.
Ensure that the relational database
is installed and running.
Table 3. Oracle database installation and configuration checklist
Task Resource Value

Determine whether to migrate an Oracle documentation
existing Oracle instance to UTF-8
code page.
Decide whether to configure the Oracle documentation
database for improved performance.
You need to do this before starting
Content Server.
Set up the networking parameters. “Oracle requirements, page 47”
Ensure that the database aliases Oracle documentation and
are in the tnsnames.ora file on the “Entries in tnsnames.ora file,
Content Server host. page 47”
Ensure that the Oracle Listener is Oracle documentation

running on the Oracle host.
Ensure that the Oracle optimizer “Oracle requirements, page 47”
meets EMC Documentum
recommendations.

Table 4. DB2 database installation and configuration checklist
Task Resource Value

Decide whether to configure DB2 documentation and DB2
the database for improved requirements, page 50
performance. You need to do
this before starting Content
Server.
Table 5. DB2 database installation and configuration checklist
Task Resource Value

DB2 documentation and DB2
requirements, page 50
Obtain the database alias name. “DB2 requirements, page 50” database alias name:
__________
Ensure that the DB2 clients are “DB2 requirements, page 50”
installed on the Content Server host.
Set the DB2 registry environment DB2 documentation 1208
variable DB2CODEPAGE
Table 6. SQL Server database installation and configuration checklist
Task Resource Value

Configure open database “Configuring an ODBC Data
connectivity (ODBC). Source for SQL Server, page 48”
Use a full SQL Server installation by SQL Server documentation
using the Custom option.
Ensure that the SQL Server sort SQL Server documentation
order is set to Dictionary.
Ensure that case-sensitivity and SQL Server documentation
row-level locking are enabled.
If SQL Server uses Windows SQL Server documentation
authentication, ensure that the
installation owner has system
administrator privileges in SQL
Server.
Ensure that the repository owner “SQL Server requirements, page
and installation owner meet the 48”
requirements.
Install the SQL Server client on the SQL Server documentation
Content Server host.

Task Resource Value

If SQL Server is installed remotely, SQL Server documentation
install Microsoft Data Access
Components 2.71 on the Content
Server host.
Install SQL Server for “SQL Server requirements, page
internationalization. 48”
Table 7. Sybase database installation and configuration checklist
Task Resource Value

In the $SYBASE/server_name.cfg file, “Sybase requirements, page 49“
set the system parameters number and Sybase documentation.
of open objects, number of open
indexes, and number of locks.
Set the page size to a minimum size Sybase documentation and
of 8 KB. “Sybase requirements, page 49”
Ensure that the Sybase version is at Sybase documentation
least 12.5.
Ensure that the Sybase directory Sybase documentation and
structure is correct. “Sybase requirements, page 49”
Requirements for all databases

Database tables store attribute values for each object in the repository. This section discusses
requirements and decisions that apply to all database vendors.
Database code page

For new repositories, install the database by using the Unicode code page, which can accurately
store characters from all supported languages.
• On Oracle, DB2, and Sybase use UTF-8.
• On SQL Server, you can use any collation (SQL Server’s name for code page), because this only
determines the code page of varchar and char types. For new SQL Server repositories, Content
Server uses only nvarchar and nchar types, which automatically use Unicode. If you need
to determine the collation settings of an existing SQL Server database, use the system stored
procedure sp_helpsort or view the properties of the particular database in Enterprise Manager.

Database versions
Typically, Content Server is installed on the English version a database. However, Content Server
installation is also supported on localized databases if the database fulfills the following criteria:
• Database supports internationalization of locales (I18N)
• Database and adheres to I18N standards
• Content Server installation is done with UTF8 and case sensitive (SQL)
Database service on Windows

If Content Server and the database are located on the same Windows host, ensure that the database
service is set to start automatically. Content Server installation sometimes requires a restart of
the computer. After the restart, installation does not proceed correctly unless the database starts
automatically.
Repository owner account

Content Server uses the repository owner (database user) account to connect to the database. Content
Server runs as the installation owner, but a separate database user account must exist to provide the
server with access to the database tables underlying the repository. Each repository must have a
unique repository owner and each repository owner must have a unique database account.
You can create the repository owner account, the database user account, and the database or
tablespace that the repository uses before Content Server installation, or the server installation
software can create the account and database or tablespace.
Note: On Oracle databases, if you create the account before Content Server installation, provide
a value for the select_catalog_role parameter.
The account must have the appropriate privileges to perform the following tasks:
• Connect to the database.
• Create tables, views, and indexes in the database.
• Insert records (rows) into the tables.
• Drop tables, views, and indexes.
The names of the privileges depend on the RDBMS. If you create the account before running the
installer, give the account these privileges:
• On Oracle, the repository owner must have Connect and Resource privileges. The Resource
privilege encompasses creating and maintaining database objects. The repository owner also
must have permission to create any view, resource, and unlimited tablespace. The tablespace
created by the repository owner for tables or indexes must be designated the default, while the
standard Oracle temporary tablespace must be the default for any temporary tables that the
repository owner creates. The name of the temporary tablespace needs to be valid for the Oracle

configuration used. The default name is either temporary_data or temp, depending on which
Oracle version is used.
The repository must also have the Select Catalog Role privilege.
• On DB2, grant use of tablespaces, list tablespace, and connect to database privileges.
On DB2, the repository owner does not have an account. The repository owner is created when
you grant the required privileges to an existing operating system account.
• On all supported SQL Server versions, the repository owner must be able to access tempdb, and if
the account is created before running the installer, the user must own all tables and views. Ensure
that the repository owner has the Create Any Database privilege.
• On Sybase, the repository owner must be able to execute procedures and update statistics.
If you allow the Content Server Setup program to create a database account for the repository owner,
the proper privileges are granted to the repository owner automatically.
Database administrator account

Regardless of the database you use with Content Server, you need to know the database
administrator’s username and password. This information is needed to create the repository owner
account in the database if you choose to have Content Server installation software create the account
for you.
You can create the repository owner account in the database in one of two ways:
• Create the account in the database before installing Content Server. During Content Server
configuration, provide the username and password for the existing user account. Repository
owner account, page 45, provides information about the required privileges for the repository
owner account.
• Allow the Content Server configuration program to create the user in the database. Provide the
username and password for a new database user during Content Server configuration. The
default username is the repository name. The Content Server configuration program gives the
appropriate privileges to the repository owner.

Oracle requirements
The Oracle RDBMS must meet these requirements:
• On UNIX and Linux, ensure that these environment variables are set in the installation owner’s
environment:
— ORACLE_HOME
— TNS_ADMIN
This environment variable points to the location of the tnsnames.ora file. The Content Server
installation program looks first for TNS_ADMIN, then for ORACLE_HOME, in order to locate
the tnsnames.ora file.
• If you are installing Content Server with Oracle Real Application Clusters, set the value of the
Oracle parameter MAX_COMMIT_PROPAGATION_DELAY to zero. This value is required to
ensure that the data that Content Server uses is consistent across all Oracle nodes. Values other
than zero are not supported.
• In the init.ora file or spfile, use the following settings:
optimizer_index_cost_adj=5
optimizer_index_caching=95
Entries in tnsnames.ora file

Oracle database aliases (TNS aliases) are defined by entries in the tnsnames.ora file. You cannot
connect to an Oracle database without an alias. Configure the tnsnames.ora file on the Content Server
host. Use the Oracle SQL*Net configuration tool to create a database alias referring to the database
instance you plan to use for Content Server. After you create the alias, test the alias by connecting to
the Oracle database.
Entries in the tnsnames.ora file for the Oracle HTTP service and data expo service do not contain
parameters for HOST, SID, and SERVICE. If the first entry in the tnsnames.ora file is for one of these
services, the Content Server installation program is unable to parse the tnsnames.ora file and cannot
connect to the database. Make sure that the first entry in the tnsnames.ora file is not for the Oracle
HTTP service or data expo service.
The database_conn key in the server.ini file must match the database entry in the tnsnames.ora
file. If it does not, you see this error:
Error - Failed to obtain database connection information
corresponding to the repository from the server.ini file.
String index out of range: -1
Please read error log /tmp/installation_owner_name.ServerInstaller.log
for more information.
If you see this error, modify the database_conn key in the server.ini file and continue with the
installation or upgrade.

Oracle repository sizes

An Oracle repository has the following size and configuration considerations:
• In a small repository on Oracle, a single tablespace contains the data and indexes and an index
tablespace cannot be configured.
• A small Oracle repository has an initial datafile size of 100 MB.
• In a medium or large repository on Oracle, one tablespace contains the data and another
tablespace contains the indexes. An index tablespace can be configured.
• A medium Oracle repository has an initial datafile size of 180 MB and an initial index file size
of 180 MB.
• A large Oracle repository has an initial datafile size of 250 MB and an initial index file size
of 250 MB.
SQL Server requirements

The SQL Server RDBMS must meet these requirements:
• Use a full SQL Server installation on the host where SQL Server is installed. Install the SQL Server
client on the Content Server host, regardless of whether the database is local or remote.
• Use the Custom installation option so that you can set the database code page, case-sensitivity,
and other options.
• You need to install the SQL Server instance in SQL Server and Windows Authentication mode.
Caution: Install the database in case-sensitive mode with row-level locking enabled. If you
installed SQL Server in case-insensitive mode, you need to reconfigure the database before you
install or upgrade Content Server.
Configuring an ODBC Data Source for SQL Server

SQL Server requires you to add a DSN entry manually. If you have two SQL Server instances on the
same host, enter hostname/instancename, when you provide the SQL Server name.
The SQL Server documentation contains instructions on how to configure an open database
connectivity (ODBC) data source for a new installation of SQL Server. When choosing an
authentication method for SQL Server to use, consider the following:
• When prompted for the name of the new data source, type the name of the host on which you are
configuring ODBC and installing Content Server.
• When creating the ODBC data source, you can choose either Windows authentication or SQL
Server authentication as an authentication method.

Note: This applies only to the ODBC data source.

— If you choose Windows authentication for the creating of the ODBC data source, the database
user (repository owner) must have a Windows account and the installation owner must have
System Administrator privileges in SQL Server.
— If you choose SQL Server authentication, the database user (repository owner) does not have to
have a Windows account.
However, when installing the entire SQL server instance, you need to install it in SQL Server and
Windows authentication mode.
When configuring the client, consider the following:
• If SQL Server is on the same host as Content Server, select Named Pipes.
• If SQL Server is on a different host from Content Server, select TCP.
SQL Server repository sizes

An SQL Server repository has the following size and configuration considerations:
• In a small repository on SQL Server, you can change the log file size, but you cannot change the
device size for the database.
• A small SQL Server repository has a datafile size of 100 MB and a log file size that is 30% of
the size of the datafile.
• In a medium or large repository on SQL Server, you can change the device size and the log file
size for the database.
• A medium SQL Server repository has a datafile size of 180 MB and a log file size that is 30%
of the size of the datafile.
• A large SQL Server repository has a datafile size of 500 MB and a log file size that is 30% of
the size of the datafile.
Sybase requirements
The Sybase RDBMS installation must meet these requirements:
• In the $SYBASE/$SYBASE_ASZserver_name.cfg file, set the following system parameters to the
values shown.
number of open objects = 4000
number of open indexes = 3000
number of locks = 35000
number of user connections = 200
procedure cache size = 48000
number of open partitions =2500

Note: For Sybase 15.0, increase the number of open partitions.

• Ensure that the correct Sybase environment variables are set in the installation owner’s
environment:
— SYBASE
— SYBASE_OCS
For Sybase 15.0, set this variable to OCS-15_0. The Sybase documentation set has detailed
information on how to set this variable.
— SYBASE_SYSAM
— SYBASE_JRE
— SYBASE_ASE
If these Sybase environment variables are not set, you see ct_init (CS_VERSION_100) errors.
Appendix A, Required Environment Variables for UNIX and Linux contains information about
these variables.
• In a new repository, set a page size of 8 KB.
• You can improve performance of some EMC Documentum scripts by increasing the network
packet size to 4 K or 8 K.
• On Sybase versions 12.0 and later, ensure that the file isql exists in the directory
$SYBASE/SYBASE_OCS/bin/isql.
• If you are using file system devices rather than raw devices, you can manually reset the dsync
option on the tempdb devices by using the sp_deviceattr.
• Increase the number of available user connections to at least 200.
Sybase repository sizes

A Sybase repository has the following size and configuration considerations:
• In a small repository on Sybase, you can change the log file size, but you cannot change the
device size for the database.
• A small Sybase repository has a datafile size of 100 MB and a log file size of 100 MB.
• In a medium or large repository on Sybase, you can change the device size and the log file size
for the database.
• A medium Sybase repository has a datafile size of 180 MB and a log file size of 180 MB.
• A large Sybase repository has a datafile size of 800 MB and a log file size of 250 MB.
DB2 requirements
The DB2 configuration requirements apply whether DB2 and Content Server are running on
Windows or AIX or a combination.

On AIX, ensure that the following DB2 environment variables are set in the installation owner’s
environment:
• Update the database configuration for the database to 200 using the following command:
MAXAPPLS 200 AUTOMATIC MAXLOCKS 80 AUTOMATIC
• DB2_BASE
This must point to /DB2_installation_dir/home/instance_name/sqllib.
• DB2INSTANCE
This must point to the name of the default DB2 instance.
• To support audit trail functionality, DB2 requires 8K-page capability. During the installation
of version 6.5, the installer automatically creates 8K pages. To find out whether you have 8K
temporary tablespace before an installation or upgrade, run the following command:
db2 LIST TABLESPACES SHOW DETAIL
If the page size parameter is 4096, you have 4K page size, if it is 8192, you have 8K page size.
To create an 8K temporary tablespace, run the following command:
db2 CREATE TEMPORARY TABLESPACE TEMPSPACE2 PAGESIZE = 8192
• Ensure that the LIBPATH environment variable includes $DB2_BASE/lib.

Do not set the environment variable DB2OPTIONS. If set to T, the DB2 command-line processor uses
a semicolon (;) as the statement termination character. Content Server does not install properly
on AIX with DB2 when DB2OPTIONS is set.
• Before you create a database for use by Content Server, disable the DB2CODEPAGE environment
variable from the command line:
db2set DB2CODEPAGE =
• Ensure that the DB2 clients are installed on the Content Server host.
— If you install DB2 on the same host as the Content Server, the clients are installed automatically.
— If you install DB2 on a different host from the Content Server, you need to manually install
the DB2 clients on the Content Server host.
• Set the code page to UTF-8.
• Set the DB2NTNOCACHE environment variable:
db2set DB2NTNOCACHE=1
You can create the database and set the parameters from the DB2 command line or from the Control
Center. Use the Control Center to run the performance wizard. You can run the Control Center
on AIX, or you can run performance wizard from a Windows system to tune performance for the
instance on AIX.
Use the following general guidelines to install and configure DB2:
1. Install DB2.
2. Optionally, use the performance wizard to fine-tune DB2 performance.
You can use the performance wizard at a later time (after you complete configuring DB2), but if
you do so, ensure that the parameter values required by Content Server are not changed.
3. Configure DB2.

DB2 performance wizard requirements

Using the DB2 performance wizard has the following requirements:
• Set the server memory target value.
— If DB2 is installed on the Content Server host and you are installing DB2 Enterprise Edition, set
the target memory to 40%.
— If DB2 is installed on the Content Server host and you are installing DB2 Workgroup Edition,
set the target memory to 20%.
— If DB2 is installed on a different host from Content Server and you are installing DB2
Enterprise Edition, set the target memory to 80%.
• Ensure that the buffpage value is at least 6000.
Running multiple Content Servers on the DB2 host

If you run multiple Content Servers on the DB2 host, you might see a DB2 SQL1224N error. This
can occur with multiple repositories on the host or with multiple servers that run against a single
repository. To work around this, change the following parameters:
• On AIX, set EXTSHM to ON in the environment of the DB2 instance owner. You can do this in the
.cshrc file or the corresponding system file for the different shells.
setenv EXTSHM ON
• On Windows, set the EXTSHM environment variable at the system level.

• In the DB2 environment, type this command:
db2set DB2ENVLIST=EXTSHM
DB2 repository sizes

DB2 repositories have the following size and configuration considerations:
• In a small repository on DB2, a single tablespace contains the data and indexes, and you cannot
change an index tablespace.
• A small DB2 repository has an initial datafile size of 200 MB.
• In a medium or large repository on DB2, one tablespace contains the data and another tablespace
contains the indexes, and you can change an index tablespace.

• A medium DB2 repository has an initial datafile size of 400 MB and an initial index file size
of 200 MB.
• A large DB2 repository has an initial datafile size of 800 MB and an initial index file size of 300 MB.


Chapter 4
Installing Content Server
Content Server installation has two stages: The first stage copies Content Server software from the
installation media to the proper directories on the Content Server host and, on Microsoft Windows
hosts, modifies the Windows registry and environment variables. The second stage starts Content
Server and configures the repository and the connection broker service.
This chapter contains step-by-step instructions for installing Content Server software and running the
configuration program to create a connection broker and repository. After the installation, complete
the tasks described in Chapter 5, Completing the Installation. To upgrade from a previous release of
Content Server, complete the preparatory steps described in Chapter 6, Upgrading Content Server
before installing the new version of Content Server.
You can choose to perform an express installation or a custom installation. Express installation
minimizes the amount of information that you need to provide during installation. It also limits how
much you can customize the configuration of Content Server and repository. The procedure for
installing and configuring Content Server on Windows and Linux and UNIX hosts calls out explicitly
those steps required for custom installation and configuration only and those required for express
installation only. Otherwise, the steps apply to both installation methods.
This chapter contains these sections:
• Installation and configuration checklist, page 55
• Installing Content Server software on a UNIX or Linux host, page 57
• Installing Content Server software on a Windows host, page 60
• Configuring Content Server and the repository on a UNIX or Linux host, page 63
• Configuring Content Server and the repository on a Windows host, page 68
• Reviewing the Content Server installation logs, page 74
Installation and configuration checklist

Before installing Content Server, use the following installation and configuration checklist to review
related documentation and make decisions about your installation. Note any values you will be asked
to enter during the installation in the Value column.

Table 8. Content Server installation and configuration checklist
Task Resource Value

Review the Content Server Release
Notes for the server release you are
installing.
Decide whether to install a small, Size of repository to create,
medium, or large repository. page 22
Decide whether to enable extended Extended services products to
services products, such as: license, page 26
• Trusted Content Services
• Content Services for EMC Centera
• SnapLock
• High-Volume Server
• Content Storage Services
• Retention Policy Services
• Physical Records Manager

Review the Content Server-specific Chapter 3, Preparing the
information for the database. Database for Content Server
Installation.
For SQL Server, obtain the ODBC data Configuring an ODBC Data
source name Source for SQL Server, page
48and the database vendor’s
documentation
Determine the installation owner Setting up the installation owner installation owner
username and password. account, page 33 and consult username:
the database administrator. __________
installation owner
password:
__________
Choose the repository name. The name for a repository repository name:
can have up to 32 characters, __________
and must consist of letter,
numbers, or underscores (_).
The first character must be a
letter. Do not include spaces or
nonalphanumeric characters.
All letters and numbers in the
name must be ASCII characters.
The repository name “docu” is
reserved by EMC Documentum.

Task Resource Value

Choose the repository ID. The repository ID can be any repository ID:
number from 1 to 16777215 and __________
must not start with a zero (0).
Repository IDs must be unique
on the network.
Obtain the repository owner name Setting up user accounts, page repository owner
(database user) and password. 33 name:
__________
repository password:
__________
Obtain the database administrator Database administrator database administrator
name and password. account, page 46 and the name:
database administrator __________
database password:
__________
Create an estimate of the repository Size of repository to create, repository size:
size. page 22 __________
If you assign the Content Server file • Content Server and
store to a shared folder on the network the file store need
with a UNC path, you need to meet the to be on the same
criteria listed in the Value column. domain
• The installation user

account of Content
Server needs to be
available on the
domain.
• The installation user

account needs to
have full access
control for the
filestore.
Installing Content Server software on a UNIX

or Linux host
The first part of the installation process copies files from the installation media to the correct
directories on the hard disk.
Have all checklists from the previous chapters ready before you begin with the installation.
Note: Displaying the installer remotely across platforms is not supported.

Note: Because of additional new features and functionality, installation of Content Server 6.5 takes
approximately 50 percent more time than the installation of version 5.x.
To install Content Server

1. Log in to the host system using the installation owner account.
Setting up the installation owner account, page 33 provides information about the installation
owner account.
2. Download the Content Server software for your operating system and database.
You can find the location of the software and instructions for downloading it in the Content Server
Release Notes or in the instructions you received through email regarding how to download
products from the EMC download site.
3. Expand the compressed archive by typing:
% tar -xvf filename
4. If you are running from a UNIX environment, ensure that you have execute permission on the
#####.bin file. You can verify this by running the chmod +x ###.bin” command.
5. Run the installation program from the directory into which you expanded the files, which must
be a directory on the local host by typing the following:
% serveroperatingsystemSuiteSetup.bin
operatingsystem is the operating system on which you are installing.
The installation program starts and a Welcome dialog box appears. The Welcome dialog box lists
the products and components that the program makes available for installation.
6. Read the Welcome dialog box and click Next.
The software license agreement appears.
7. Read the license agreement.
8. To continue with installation, click I accept the terms of the license agreement and click Next.
If you do not accept the license agreement terms, the Next button becomes unavailable, and you
cannot continue with the installation.
9. Type the host name and port number for your existing primary connection broker. The default
port number is 1489. If you are using the default port number, ensure that the next port number
(1490) is available for use because the connection broker requires that two ports be reserved.
You can configure additional connection brokers by using the Content Server configuration
wizard.
Note: If you already have EMC Documentum software installed on the host, the installation
program will skip this step because you installed a connection broker with the previous
installation of the EMC Documentum software.
10. To enable Enterprise Content Integration (ECI) services, select the check box.
If you choose not to enable ECI services, leave the check box blank, and click Next.
If you choose to enable ECI, type the ECI services host name and the ECI services RMI port
number. The default port number is 3005. Click Next.
11. Type the password for the installation owner and click Next.

The dialog box shows the username and domain for the currently logged-in user. This user will
be the installation owner. When you click Next, the installation program validates the password.
12. To enable the High-Volume Server, select the check box, type the High-Volume Server license
key, and click Next.
13. To enable Trusted Content Services, select the check box, type the Trusted Content Services
license key, and click Next.
Note: Archive Services for Reports (ASR) does not work when Trusted Content Services is
enabled.
14. To enable Content Services for EMC Centera, select the check box, type the Content Services
for EMC Centera license key, and click Next.
15. To enable SnapLock, select the check box, type the SnapLock license key, and click Next.
16. To enable XML Store integration, select the check box, type the license key, and click Next.
If you choose not to enable XML Store integration, leave the check box blank and click Next.
If you choose to enable XML Store integration type the XML Store port number and directory
location. Click Next.
17. You can install the DFC developer documentation.
a. To install the DFC developer documentation, select the Developer Documentation check box.
b. Click Next.
Installing developer documentation requires an additional 18 MB.
18. Enter the connection information for the application server that Content Server installs for its
private use.
a. Type the password for the administration user in the Admin User Password and Re-enter
Password fields. You will use this password and the username admin to access the
administration console for the application server. The password must be at least five
characters long, and it cannot contain double or single quotation marks (“ or ’).
b. Type the port number to use as the primary port for communications between the application
server and Content Server. The default port is 9080. The selected port must not be used by
another application. A total of 20 ports starting at port number 9080 are reserved for this
application server instance, and all of them must be available.
c. Click Next.
19. Type a password for managing Accelerated Content Services (ACS) configuration and properties
files.
Accelerated Content Services is a Content Server component used for exchanging content with
Web-based client applications. Use the username acsAdmin and the specified password to access
the components that are used for modifying Accelerated Content Services configuration settings.
a. Type the password for the acsAdmin user in the Password and Confirm password fields.
b. Click Next.
A panel displays the software to be installed.
20. Click Next to begin the software installation.
The dialog box reports the progress of the installation. If any components already exist on the
host, click Yes or Yes to All to replace the older components.

21. Choose whether to run the dm_root task automatically or manually at a later time. For
instructions on how to run the dm_root task manually, see Running dm_root_task manually
on UNIX or Linux hosts, page 75.
22. Click Finish to exit the Content Server installation program.
Installing Content Server software on a

Windows host
The first part of the installation process copies files from the installation media to the correct
directories on the hard disk.
On Windows, this procedure also sets environment variables needed by Content Server. On
Windows, if you exit the Setup part of the installation program, all Content Server registry entries
are deleted. To install a component that was not previously installed, go through the complete
Setup program.
Have all checklists from the previous chapters ready before you begin with the installation.
Note: Displaying the installer remotely across platforms is not supported.
To install Content Server:

1. Log in to the host system using the installation owner account.
Setting up the installation owner account, page 33 provides information about the installation
owner account.
2. Download the Content Server software for your operating system and database.
You can find the location of the software and instructions for downloading it in the Content Server
Release Notes or in the instructions you received through email regarding how to download
products from the EMC download site.
3. Expand the compressed archive by double-clicking the file.
4. Run the installation program from the directory into which you expanded the files, which must
be a directory on the local host. Double-Click the serverWinSuiteSetup.exe file.
The installation program starts and a Welcome dialog box appears. The Welcome dialog box lists
the products and components that the program makes available for installation.
5. Read the Welcome dialog box and click Next.
The software license agreement appears.
6. Read the license agreement.
7. To continue with installation, click I accept the terms of the license agreement and click Next.
If you do not accept the license agreement terms, the Next button becomes unavailable, and you
cannot continue with the installation.
8. If you are installing on a Windows host that has no other EMC Documentum software installed
on it, choose the installation directory for Content Server.

If you previously installed EMC Documentum software on the host, the relevant directories
might already be set. Skip to Step 16
Click Next to accept the default directory (C:\Documentum) where Content Server and data
installation or click Browse to select a different installation directory. The name of the directory
in which Content Server is installed must contain only ASCII characters and must not include
spaces. Do not use any of these characters in pathnames: ! \ / : * ? " < > | .
9. You can install the DFC developer documentation.
a. To install the DFC developer documentation, select the Developer Documentation check box.
b. Click Next.
10. If DFC is not already installed on the host, click Next to accept the default installation directory
(C:\Program Files\Documentum,) for shared programs such as DFC or click Browse to select
a different directory.
If DFC is already installed on the host, the Content Server installation program uses the existing
DFC installation directory.
11. Select a user directory. You can either accept the default user directory C:\Documentum and
click Next or click Browse to choose another directory.
EMC Documentum products use the user directory to store working files, program settings,
and log files.
12. Type the host name and port number for your existing primary connection broker. The default
port number is 1489. If you are using the default port number, ensure that the next port number
(1490) is available for use because the connection broker requires that two port numbers be
reserved.
You can configure additional connection brokers by using the Content Server configuration
wizard.
Note: If you already have EMC Documentum software installed on the host, the installation
program will skip this step because you installed a connection broker with the previous
installation of the EMC Documentum software.
13. To enable Enterprise Content Integration (ECI) services, select the check box.
If you choose not to enable ECI services, leave the check box blank, and click Next.
If you choose to enable ECI, type the ECI services host name and the ECI services RMI port
number. The default port number is 3005. Click Next.
The dialog box shows the username and domain for the currently logged-in user. This user will
be the installation owner. When you click Next, the installation program validates the password.
15. To enable the High-Volume Server, select the check box, type the High-Volume Server license
Note: If you opt to enable the High-Volume Server at a later time, you need to rerun the Content
Server installation program.
16. To enable Trusted Content Services, select the check box, type the Trusted Content Services
license key, and click Next.
17. To enable Content Services for EMC Centera, select the check box, type the Content Services
for EMC Centera license key, and click Next.

18. To enable XML Store integration, select the check box, type the license key, and click Next.
If you choose not to enable XML Store integration, leave the check box blank and click Next.
If you choose to enable XML Store integration type the XML Store port number and directory
location. Click Next.
19. To enable SnapLock, select the check box, type the SnapLock license key, and click Next.
20. Enter the connection information for the application server that Content Server installs for its
private use.
a. Type the password for the administration user in the Admin User Password and Re-enter
Password fields. You will use this password and the username admin to access the
administration console for the application server. The password must be at least five
characters long, and it cannot contain double or single quotation marks (“ or ’).
b. Type the port number to use as the primary port for communications between the application
server and Content Server. The default port is 9080. The selected port must not be used by
another application. A total of 20 ports starting at port number 9080 are reserved for this
application server instance, and all of them must be available.
c. Click Next.
21. Type a password for managing Accelerated Content Services (ACS) configuration and properties
files.
Accelerated Content Services is a Content Server component used for exchanging content with
Web-based client applications. Use the username acsAdmin and the specified password to access
the components that are used for modifying Accelerated Content Services configuration settings.
a. Type the password for the acsAdmin user in the Password and Confirm password fields.
b. Click Next.
A panel displays the software to be installed.
22. Click Next to begin the software installation.
The dialog box reports the progress of the installation. If any components already exist on the
host, click Yes or Yes to All to replace the older components.
23. Choose whether to continue to Content Server configuration.
• To configure Content Server and repositories immediately, click Configure server for new
repository or upgrade existing repository and click Next. The installation program launches
the Server Configuration program. Configuring Content Server and the repository on a
Windows host, page 68 contains the procedures for configuring Content Server and the
repository.
• To configure Content Server at another time, click Configure server later and click Next.
24. Click Finish to exit the Content Server installation program.

Configuring Content Server and the repository

on a UNIX or Linux host
This section provides instructions for configuring Content Server and a repository on a UNIX or
Linux host. Perform this part of the installation after you install the software.
To configure Content Server and the repository:

1. Start the Content Server configuration program by typing these commands:
% cd $DM_HOME/install
% "./dm_launch_server_config_program.sh
The Welcome dialog box appears.
2. Click Next.
3. Choose whether to run the dm_root task automatically or manually later. See Running the
administrative tool script manually, page 68 for details.
The dialog box shows the username and domain for the currently logged-in user, who must be
the installation owner. When you click Next, the installation program validates the password.
5. Select whether to perform an Express configuration or a Custom configuration and click Next.
• If you select Express, the configuration program creates a new connection broker using a
default name and port number, and uses default values for certain repository configuration
settings. Skip to Step 13
• If you select Custom, the configuration program enables you to edit the configuration values
used to create one or more connection brokers, a repository, or both.
6. On SQL or Oracle databases, when you configure a repository, optionally select the check box to
enable database partitioning. By default, database partitioning is disabled.
7. Choose whether to configure a connection broker, a repository, or both, and click Next.
• If you checked connection broker, the connection broker configuration appears.
• If you checked repository but not connection broker, the repository configuration appears.
Skip to Step 13 .
8. Configure a connection broker on the Content Server host.
a. Choose Create a new connection broker and click Next.
b. Type a connection broker name (default: Docbroker) and the port number on which the
connection broker listens, or accept the defaults. The default port is 1489. If you are using
the default port number, ensure that the next port (1490) is available for use because the
connection broker requires that two ports be reserved.
c. Click Automatic to have the connection broker automatically start when the host starts, or
click Manual for manual startup.

9. Select the mode in which the connection broker connects to the repository.
• Select Native for nonsecure connections.
• Select Secure for secure connections.
• Select Native and Secure if clients can use either connection mode.
10. Click Next. The connection broker is started.
11. To configure additional connection brokers on this host, select Configure an additional
connection broker and click Next. Repeat these steps, making sure to provide each connection
broker with a unique port number that is not used by another application.
To continue with the server configuration, select the Continue with server configuration check
box and click Next.
12. For custom configuration only, select Create a repository and click Next.
13. Choose whether to Create a new repository, Upgrade an existing repository, or Delete an
existing repository. Click Next.
Note: During repository configuration, if the administrative tool script does not run properly
and you see an error message, you can run it manually by using the procedure in Running the
administrative tool script manually, page 68.
14. To enable Content Storage Services, select the check box, type the license key, and click Next.
15. To enable Retention Policy Services, select the check box, type the license key, and click Next.
16. To enable Federated Records Services, select the check box, type the license key, and click Next.
17. To enable Records Manager, select the check box, type the license, and click Next.
18. To enable Physical Records Manager, select the check box, type the license, and click Next.
19. Click Next to accept the default data directory location or browse for a different location.
20. Click Next to accept the default share directory location or type a new location.
The share directory is where client products, sample code, and libraries are stored.
Note: The share directory is not the same as the $DOCUMENTUM_SHARED environment
variable. This environment variable sets the directory into which EMC Documentum Foundation
Classes and other components are installed.
21. To enable data partitioning, select the check box and click Next.
22. Provide the repository information.
a. Type the name of the repository. Name and ID to assign to the repository, page 23 contains
information about repository name requirements.
b. Type the repository ID.
c. Type a description for the repository.
d. Select the repository size.
e. Select the authentication domain.
f. Click Next.
g. Type the service name. The service name must match the entry in the /etc/services file.
23. Click Next.

24. Select whether to create a new database user account and storage areas or use an existing user
account and storage, and click Next. If you use an existing database user account, be sure that
you have previously created a database user account.
Username Content Server will use to connect to the database, page 22 contains information about
this configuration option. The database user is the repository owner.
25. If you chose to use an existing database account and tablespaces or databases, provide the
database connection information.
a. Choose the correct database connection for your database instance from the drop-down list:
• On Oracle, select the connection string.
• On DB2, select the database name.
• On Sybase, select the database name.
b. Type the username for an existing database user. This user becomes the repository owner,
and must have the privileges identified in Repository owner account, page 45.
c. Type the database user’s password.
d. Type the database administrator name.
e. Type the database administrator password.
f. Click Next.
g. For Custom configuration only, choose the correct index tablespace or datafile name. Express
configuration uses default values.
h. Click Next.
Content Server starts.
26. If you chose to create a new database user account, provide database connection information.
b. Type the database user’s name.
This user becomes the repository owner, and must have the privileges identified in
Repository owner account, page 45.
c. Type the database user’s password and confirm the password.
d. Type the database administrator’s username and password that was created when setting
up the database.
e. Click Next.
f. In a custom installation, you are prompted to either accept or change the default paths and
sizes for database storage. In an express installation the software automatically applies
the default values.
• On Oracle, these are the Data Tablespace Data File Path and Index Tablespace Data File
Path.
• On SQL Server, these are the Data Device File Path and Log Device File Path.

• On Sybase, these are the Data Device File Path and Log Device File Path.
• On DB2, these are the Tablespace File Path and Index Data File Path.
The tablespace or database creation dialog box appears.
g. Click Next.
h. For custom configuration only, edit or accept the default database scripts. Express
configuration runs the default scripts.
• To edit the tablespace or database creation or deletion script, select the script and click
Edit. When you have saved the file, click Next.
• To accept the default scripts and run them, click Next.
The new tablespaces or databases are created.
27. For custom configuration only, accept or modify Content Server initialization values. Express
configuration uses the default initialization file.
The server.ini file contains Content Server initialization information. If you are installing on
DB2 or Oracle and you want to modify the database parameters for the repository tables, edit
the server.ini file during this step. You cannot change these parameters after Content Server
creates the database tables for the repository. Appendix E, Defining Oracle or DB2 Database
Parameters for Repository Tables contains descriptions of the DB2 and Oracle parameters for
repository tables.
• To accept the files, click Next.
• To edit the server.ini file, select Server Initialization File and click Edit. After you save the
file, click Next.
28. Optionally, you can edit a tablespace script by clicking Edit.
29. Optionally, you can edit an initialization file by clicking Edit.
Caution: Errors in the server.ini file can cause problems with Content Server startup.
30. Click Next.
The configuration program runs the repository configuration scripts based on the settings you
provided.
31. If you don’t already have designates a global registry, decide here whether to designate the
current repository as a global registry.
Repository to use as the global registry, page 25 contains details on determining which repository
to designate as the global registry.
• To use the current repository as a global registry, select Use this Repository and click Next.
• To use a different repository as the global registry repository, select Specify a Different
Repository and click Next
• To designate the global registry repository at a different time, select Do Later and click Next.

32. Type the connection information for the global registry.

• If you chose the current repository as a global registry, type a username and password for the
global registry user and click Next. The default username is dm_bof_registry.
• If you chose to use a different repository as a global registry, type the repository name and
the global registry user’s username and password. The repository must be known to the
connection broker.
• If you chose Do Later, the global registry connection page does not appear.
A warning message to enable the global registry connection appears. Click CONTINUE.
33. For custom configuration only, accept or modify the repository configuration scripts. Express
configuration runs the scripts without modification.
Appendix B, Content Server Installation Directories and Repository Configuration Scripts
contains information on what each of the scripts does.
• To accept the scripts, click Next.
• To edit a script, select it and click Edit. After you edit and save all the scripts you are
modifying, click Next.
Caution: Use caution in editing the scripts. Errors in the scripts can cause problems in
the repository.
When you click Next, the repository configuration scripts run, and the bundled DARs are also
installed. A message appears when these tasks are completed.
34. Click Next.
35. Choose whether to restart Content Server to enable SSL client connections.
• To enable SSL client connections, click Restart repository now and click Next.
Content Server stops and is restarted.
• To restart Content Server at a different time, click Restart repository later and click Next.
36. For custom configuration only, choose whether to configure additional repositories on the host.
Express configuration skips to the next step.
• To configure additional repositories, select the check box and click Next. The configuration
program returns to Step 13.
• To continue, select Exit from the Content Server configuration, and click Next.
A summary appears with information about the products configured on the host.
37. Click Finish.
38. On AIX, restart Content Server.
This loads required fulltext plugins.
The Content Server Fulltext Indexing System Installation and Administration Guide provides instructions
on how to install the fulltext indexing software.

Running the administrative tool script manually

During Content Server installation, if you opt not to run the tool script automatically or if the
administrative tool script does not run properly and you see an error message, you can run it
manually by using the following steps.
To complete the installation and run the administrative tool script:

1. Click OK to close the error message.
2. On the dialog box, clear the Run Script Again box and click Next.
3. Complete the installation.
4. Type the following command:
• For Windows:
ddmbasic -f %DM_HOME%\install\admin\toolset.ebs -P repository_name
%DM_HOME%\install\admin database_connection_string -e ToolSetup
• For UNIX
dmbasic -f $DM_HOME/install/admin/toolset.ebs -P repository_name
$DM_HOME/install/admin database_connection_string -e ToolSetup
Windows example for repository TestA:

dmbasic -f %DM_HOME%\install\admin\toolset.ebs -P TestArepository
%DM_HOME%\install\admin connect1.documentum.com -e ToolSetup
UNIX example for repository TestA:
dmbasic -f $DM_HOME/install/admin/toolset.ebs -P TestArepository
$DM_HOME/install/admin connect1.documentum.com -e ToolSetup
Configuring Content Server and the repository

on a Windows host
This section provides instructions for configuring Content Server and a repository on a Windows
host. Perform this part of the installation after you install the software.
To configure Content Server and the repository:

1. Start the Content Server configuration program.
You can start the configuration program directly from the Content Server installation program, or
you can start it from the operating system:
Log in to Windows as the installation owner, navigate to the %DM_HOME%\install directory,
and launch Server_Configuration_Program.exe.
2. Click Next.

4. Select whether to perform an Express configuration or a Custom configuration and click Next.
• If you select Express, the configuration program creates a new connection broker using a
default name and port number, and uses default values for certain repository configuration
settings. Skip to Step 13.
• If you select Custom, the configuration program enables you to edit the configuration values
used to create one or more connection brokers, a repository, or both.
5. On SQL or Oracle databases, when you configure a repository, optionally select the check box to
enable database partitioning. By default, database partitioning is disabled.
6. Choose whether to configure a connection broker, a repository, or both, and click Next.
• If you checked connection broker, the connection broker configuration appears.
• If you checked repository but not connection broker, the repository configuration appears.
Skip to Step 13 .
connection broker listens, or accept the defaults. The default port is 1489. If you are using the
default port number, ensure that the next port number (1490) is available for use because
the connection broker requires that two ports be reserved.
8. Select the mode in which the connection broker connects to the repository.
• Select Native for nonsecure connections.
9. Click Next. The connection broker is started.
10. To configure additional connection brokers on this host, select Configure an additional
connection broker and click Next. Repeat these steps, making sure to provide each connection
broker with a unique port number that is not used by another application.
To continue with the server configuration, select the Continue with server configuration check
box and click Next.
11. For custom configuration only, select Create a repository and click Next.
12. Choose whether to Create a new repository, Upgrade an existing repository, or Delete an
existing repository. Click Next.
Note: During repository configuration, if the administrative tool script does not run properly
and you see an error message, you can run it manually by using the procedure in Running the
administrative tool script manually, page 68.
13. Configure a repository.
14. To enable Content Storage Services, select the check box, type the license key, and click Next.

15. To enable Retention Policy Services, select the check box, type the license key, and click Next.
16. To enable Federated Records Services, select the check box, type the license key, and click Next.
17. To enable Records Manager, select the check box, type the license, and click Next.
18. To enable Physical Records Manager, select the check box, type the license, and click Next.
19. Click Next to accept the default data directory location or browse for a different location. The
default location is C:\Dcoumentum\data.
20. Click Next to accept the default share directory location or type a new location. Express
configuration uses the default directory C:\Documentum\share.
variable. This environment variable sets the directory into which EMC Documentum Foundation
Classes and other components are installed.
21. To enable data partitioning, select the check box and click Next.
22. Provide the repository information.
a. Type the name of the repository. Name and ID to assign to the repository, page 23 contains
b. Type the repository ID.
c. Type a description for the repository.
d. Select the repository size.
e. Select the authentication domain.
f. Indicate whether Content server starts automatically or manually. Check Automatic to
start Content Server automatically when the host starts or Manual to start Content Server
manually.
g. Click Next.
23. Select whether to create a new database user account and storage areas or use an existing
database user account and storage, and click Next. If you choose the option to use an existing
database user account, you must have created a database user account previously.
Username Content Server will use to connect to the database, page 22 contains information about
this configuration option. The database user is the repository owner.
24. If you chose to use an existing database account and tablespaces or databases, provide the
database connection information.
• On SQL Server, select an ODBC data source.
b. Type the username for an existing database user. This user becomes the repository owner,
and must have the privileges identified in Repository owner account, page 45.


d. Type the database administrator name.
e. Type the database administrator password.
f. Click Next.
g. For Custom configuration only, choose the correct index tablespace or datafile name. Express
configuration uses default values.
h. Click Next.
Content Server starts.
25. If you chose to create a new database user account, provide database connection information.
• On SQL Server, select an ODBC data source.
d. Type the database administrator’s username and password that was created when setting
up the database.
e. Click Next.
f. In a custom installation, you are prompted to either accept or change the default paths and
sizes for database storage. In an express installation the software automatically applies
the default values.
• On Oracle, these are the Data Tablespace Data File Path and Index Tablespace Data File
Path.
• On SQL Server, these are the Data Device File Path and Log Device File Path.
• On Sybase, these are the Data Device File Path and Log Device File Path.
• On DB2, these are the Tablespace File Path and Index Data File Path.
The tablespace or database creation dialog box appears.
g. Click Next.
h. For custom configuration only, edit or accept the default database scripts. Express
configuration runs the default scripts.
Edit. When you have saved the file, click Next.

26. For custom configuration only, accept or modify Content Server initialization values. Express
configuration uses the default initialization file.
repository tables.
file, click Next.
27. Click Next.
The installation program runs the repository configuration scripts based on the settings you
provided.
28. Configure the data files or data devices’
a. Type the data tablespace data file path.
b. Type the file size.
c. Type the tablespace data file path.
d. Type the file size.
29. Optionally, you can edit a tablespace script by clicking Edit.
30. Optionally, you can edit an initialization file by clicking Edit.
Caution: Errors in the server.ini file can cause problems with Content Server startup.
31. Provide the SMTP server information. The SMTP server is used to send email notifications to
the installation owner and repository users.
a. Type the name or IP address of a computer on the network that hosts an SMTP server.
The computer can be a remote host or the computer that hosts Content Server. All UNIX
operating systems and Windows 2000 Server include an SMTP server.
b. Type the installation owner’s email address.
c. Click Next.
32. Decide whether to designate the current repository as a global registry.


connection broker.
34. For custom configuration only, accept or modify the repository configuration scripts. Express
configuration runs the scripts without modification.
the repository.
36. For custom configuration only, choose whether to configure additional repositories on the host.
Express configuration skips to the next step.
• To configure additional repositories, select the check box and click Next. The configuration
program returns to Step 13.
• To continue, select Exit from the Content Server configuration, and click Next.
A summary appears with information about the products configured on the host.
37. Click Finish.
38. On AIX, restart Content Server.
This loads required fulltext plugins.
The Content Server Fulltext Indexing System Installation and Administration Guide provides instructions
on how to install the fulltext indexing software.

Reviewing the Content Server installation logs

The Content Server installer and configuration program both create log files. The log files may
be stored in one of the following directories:
• The current working directory.
For the installation program, the current working directory is the directory from which you
started the program. For the configuration program, the current working directory is typically
$DM_HOME/install (UNIX) or %DM_HOME%\install (Windows).
• The parent directory of the installation directory, if the installation owner does not have write
permission on the current working directory.
• The user’s home directory, if the installation owner does not have write permission on the parent
directory.
The log filenames are install.log and installation_owner_username.ServerConfigurator.log.
Each script that runs during repository configuration creates a log file. These are stored in the
$DOCUMENTUM/dba/config/repository_name directory.
Content Server stores other log files in the $DOCUMENTUM/dba/log directory. After you install or
upgrade Content Server, examine the log file for the repository for error reports. The log is called
repository_name.log.save.date.time. repository_name is the name of the repository you created or
upgraded, and date and time are the date and time the log was saved.
Another log file is $DM_HOME/install/SetupError.log, which contains information on the operating
system environment, the Content Server version, Java environment, and hardware.

Chapter 5
Completing the Installation
This chapter describes required and optional tasks to perform after installing Content Server so
that users can begin working with a repository.
This chapter contains the following sections:
• Running dm_root_task manually on UNIX or Linux hosts, page 75
• Running the administrative tool script manually, page 68
• Changing the default passphrase, page 76
• Changing the installation owner account, page 77
• Backing up key store files, page 79
• Starting Content Server and the connection broker, page 79
• Adding users and groups to a repository, page 80
• Enabling jobs after installation, page 80
• Creating additional repositories or connection brokers, page 81
Running dm_root_task manually on UNIX or

Linux hosts
The Content Server installation program offers the option to run the dm_root_task script
automatically. contains details. If you chose not to have the installation program run it or if
dm_root_task does not run correctly during Content Server installation, the file permissions are
incorrect on the dm_check_password and dm_change_password programs, which are required for
user authentication. You can run the dm_root_task script manually.
To run the dm_root_task manually:

1. Log in as the root user.
2. Navigate to the $DOCUMENTUM/dba directory.
3. Run the task:
dm_root_task
The script runs.

4. Type the name of the administrators group and press return.

The permissions on the files are changed.
Changing the default passphrase

During Content Server installation, a key store is created that contains a passphrase that is used for
encryption. After installation, change the default passphrase to a custom passphrase. If you create a
custom passphrase after Content Server installation, any time you restart the server host you need to
run the dm_crypto_boot utility. The Content Server Administration Guide provides instructions and
more details on encryption, key stores, and passphrases.
Binding Content Server to a network card

To configure Content Server to use a different network card, create an initialization file for the
connection broker. The file must include a [DOCBROKER_CONFIGURATION] section to identify the
IP address of the network card. Use the following format:
[DOCBROKER_CONFIGURATION]
host=IP_address_string
service=service_name
port=port_number
IP_address_string is the IP address of the network card.

The service name is the connection broker’s service name, defined in the host’s services file. The
port number is the port defined in the service.
• If you include a service name, the connection broker starts by using that service.
• If you include a port number, the connection broker starts by using that port.
• If you do not include a service name or a port number, the connection broker uses the default port
number 1489. If you are using the default port number, ensure that the next port number (1490) is
available for use because the connection broker requires that two ports be reserved.
Configuring JBoss application servers for SSL

Content Server supports the Hypertext Transfer Protocol (HTTP) and the Hypertext Transfer Protocol
over Secure Socket Layer (HTTPS). The default protocol is HTTP, but you can configure servers
bundled with JBoss application servers for HTTPS. You can configure JBoss servers by editing the
server’s configuration file. In addition, you have to configure ACS base URL using Documentum
Administrator. For information on how to configure JBoss servers using Documentum Administrator
refer to EMC Documentum Administrator User Guide.
To configure JBoss application servers for SSL:

1. Make the Java key store that was created for the server available on the Content Server host.

2. Open the JBoss server configuration file. The default location of the configuration file
is \Documentum\jboss4.2.0\server\DctmServer_MethodServer\deploy\jboss-web.
deployer\server.xml.
3. Replace the following configuration:
<Connector port="10080" protocol="HTTP/1.1" SSLEnabled="false"
maxThreads="150" scheme="https" secure="true"
keystoreFile="${jboss.server.home.dir}/conf/
my.keystore" keystorePass="changeit"
clientAuth="false" sslProtocol="TLS" />
with the following configuration:

<Connector port="<your HTTPS port of choice>"
protocol="HTTP/1.1" SSLEnabled="true"
maxThreads="150" scheme="https" secure="true"
keystoreFile="<full path to Java keystore>"
keystorePass=<keystore password>"
clientAuth="false" sslProtocol="TLS" />
4. Restart the application server.
Changing the installation owner account

By default, the user account from which you install Content Server becomes the installation owner.
After installing Content Server and configuring the repositories, you can identify a different account
as the installation owner.
To change the installation owner on UNIX or Linux:

1. In each repository in the installation, create a new user to replace the current installation owner
if needed.
The online help for Documentum Administrator provides information about creating users.
2. Set the required environment variables in the new installation owner’s environment.
3. Log in by using the account of the current installation owner.
4. Stop all Content Servers on the host.
5. Stop all connection brokers on the host by running the $DOCUMENTUM/dba/dm_stop_
docbrokerName script, where docbrokerName is the name of the connection broker.
6. Set the value for the new installation owner in the install_owner parameter of the server.ini file
located at %DOCUMENTUM%\dba\config\repository_name\server.ini.
7. Change the permissions in the data, dba, product, and share subdirectories of the
DOCUMENTUM installation root directory.
Give the permissions on these directories accorded to the previous installation owner to the
new installation owner.
To change the installation owner on Windows NT:

1. Log in as the Windows NT administrator.

The online help for Documentum Administrator provides information about creating users.
2. Stop services for all repositories and connection brokers.
3. Stop all Content Servers on the host.
4. Set the value for the new installation owner in the install_owner parameter in the server.ini file
located at %DOCUMENTUM%\dba\config\repository_name\server.ini.
5. Change the permissions in the data, dba, product, and share subdirectories of the
DOCUMENTUM installation root directory:
a. In Windows Explorer, select the directory.
b. Right-click the directory to display a menu and select Properties from the menu.
c. Select the Security tab on the Properties dialog box.
d. Click Add to add the new installation owner to the list of those with permissions on the
directory. You are prompted for the new owner’s domain.
e. Give the new owner Full Control permission.
f. Check Replace Permissions on Subdirectories and Replace Permissions on Existing Files.
g. Delete the old installation owner from the list of those with access permission on the directory.
h. Click OK.
6. Edit the Registry to reflect the change in ownership:
a. In the following key: HKEY_LOCAL_
MACHINE\SOFTWARE\Documentum\Server\version_No
i. Change the value of DM_DMADMIN_USER to the new owner.
ii. If the new owner is in a different domain, change the value of DM_DMADMIN_DOMAIN
to the domain of the new owner.
b. In the following key: HKEY_LOCAL_
MACHINE\SYSTEM\CurrentControlSet\Services\DmServerdocbasename, change the
install_owner parameter in the value for Imagepath to the new owner.
7. For each repository in the installation, use regedt32 to change the security permission on the
following Registry keys:
• HKEY_LOCAL_MACHINE\SOFTWARE\Doumentum\Server\version_No.
• HKEY_LOCAL_
MACHINE\SYSTEM\CurrentControlSet\Services\EventLog\Application\Documentum
• HKEY_LOCAL_MACHINE\SOFTWARE\Doumentum\Docbases\docbase_name
a. Select the key and right-click it to display a menu.
b. Select Security > Permissions.
c. Add the new installation owner with Full Control.
d. Delete the old installation owner.
8. For each Content Server, set the appropriate startup information:
a. Select Control Panel > Services.

b. Select the Service: Documentum Docbase docbase_name.

c. In the Startup dialog box, type the new owner and owner’s password under Log On As:
this account.
9. Move the Documentum and Documentum docbase docbase_name in the Start menu from
WinNT\Profiles\old_owner\Start Menu\Programs\ to WinNT\profiles\new_owner\Start
Menu\Programs.
10. Update the r_install_owner and r_install_domain parameters in the server_config object to reflect
the new installation owner.
11. Restart Windows NT.
Backing up key store files

After you install the Content Server and repository, back up the key store files, which are all the files
in the directory $DOCUMENTUM/dba/secure.
Starting Content Server and the connection

broker
On Windows systems, you start and stop servers and connection brokers from the Server Manager
tool. You can also launch the Content Server configuration program from Server Manager and use
it to create additional repositories or connection brokers, or to modify the existing repositories.
Creating additional repositories or connection brokers, page 81 contains details.
Note: If you create a custom passphrase after Content Server installation, run the dm_crypto_boot
utility any time you restart the server host. The Content Server Administration Guide contains detail on
the dm_crypto_boot utility.
To start Content Server and the connection broker on Windows hosts:

1. From Microsoft Windows, select Start > Programs > Documentum > Server Manager.
The Server Manager tool appears.
2. Select the tab for starting the connection broker or Content Server.
3. Highlight the name of the broker or Content Server to start.
4. Click Start.
5. Start the application server service.
a. Click Start > Programs > Administrative Tools > Services.
b. On the Services dialog box, scroll to Documentum Java method server.
c. Right-click Documentum Java method server.
d. Click Start.
e. Close the Services dialog box.

To start Content Server and the connection broker on UNIX or Linux hosts:
1. Navigate to the $DOCUMENTUM/dba directory.
2. Run the script dm_start_serverconfigname script, where serverconfigname is the object name of the
Content Server’s server config object.
3. Start the application server.
a. Navigate to the $DOCUMENTUM/jboss4.2.0/domains/DctmDomain directory.
b. Run the startMethodServer.sh script.
4. Start the connection broker by running the $Documentum/dba/dm_launch/docbrokerName script,
where docBrokername is the name of the connection broker
.
Adding users and groups to a repository

When a repository is created, it contains accounts for the repository owner, installation owner,
and several users required for Content Server functionality, but no other users and no groups. The
installation owner must add users and groups to the repository. You can add users and groups with
Documentum Administrator. The online help for Documentum Administrator and the Content Server
Administration Guide contain information on creating users and groups.
Enabling jobs after installation

Jobs are automated tools for performing repository maintenance tasks. When the repository is
installed, many jobs are in the inactive state and do not run until the state is changed to active. After
you install the repository, review the Content Server Administration Guide, Documentum Administrator
online Help, and active jobs.
Enabling the purge audit job

The purge audit job deletes old audit trail objects from the repository. The job runs as the installation
owner. However, when a repository is created, the installation owner is not granted sufficient
extended privileges to run the job.
After you create a repository, create a new user with superuser privileges, connect as that user, and
grant the installation owner account Purge Audit extended privileges.

Creating additional repositories or connection

brokers
To create additional repositories or connection brokers in a Content Server installation, do one of the
following:
1. On Windows, do the following:

• Start the Documentum Server Manager by selecting Start > Programs > Documentum >
Documentum Server Manager.
• On the Utilities tab, click Server Configuration Program.
• Use the instructions in the Content Server configuration sections, to create new repositories or
connection brokers.
2. On UNIX or Linux, do the following:
• Start the Content Server configuration program.
• Use the instructions in the Content Server configuration sections, to create new repositories or
connection brokers.


Chapter 6
Upgrading Content Server
This chapter describes how to upgrade from a previous release and how to upgrade repositories to
Content Server version 6.5. The System Upgrade and Migration Guide contains additional information
on migrating the installation from a previous version to Content Server version 6.5. The System
Upgrade and Migration Guide and the Content Server Release Notes provide information about supported
upgrade paths.
This chapter contains the following topics:
• Upgrade checklist, page 83
• Upgrading the Content Server software, page 88
Each step in the upgrade process must be to a platform that is fully supported by EMC Documentum.
Depending on the Content Server release from which you are upgrading, you might need to upgrade
the operating system or database. The documentation provided by the operating system or database
vendor contains information on upgrading those components of the system. After each upgrade step,
test the repository to ensure that all functions are normal.
Caution: After upgrading, you cannot revert to previous versions of the Content Server.
Upgrade checklist
Use the following checklist for upgrading the Content Server. In the Value column, note any values
you will be prompted for during the upgrade procedure.
Table 9. Content Server upgrade checklist
Task Resource Value

Review the Content Server Content Server Release Notes
Release Notes
Review the System Upgrade and System Upgrade and Migration
Migration Guide. Guide.

Task Resource Value

If you are installing the fulltext Content Server Fulltext
indexing components, review Indexing System Installation
the Content Server Fulltext and Administration Guide
Indexing System Installation
and Administration Guide,
and decide whether you are
performing a preupgrade or
postupgrade migration to the
new fulltext indexing system.
Back up the repository. Content Server Administration

Guide
Decide whether to enable Extended services products to
extended services, such as: license, page 26
• Retention Policy Services
• Trusted Content Services
• Content Services for EMC

Centera
• Content Storage Services
• Physical Records Manager

Temporarily increase the Database documentation
amount of rollback space
available in the RDBMS.
The number of rollback

segments should be
commensurate with the size of
the repository and should be in
segments of equal size.
Ensure that you have sufficient
disk space on the computer
hosting the database.
Run the repository consistency Content Server Administration
checker script and correct any Guide and Chapter 6,
errors you find. Upgrading Content Server
Shut down the repository and Content Server Administration
all servers running against the Guide
repository.
Shut down any local connection Content Server Administration
brokers. Guide

Task Resource Value

On Windows, set the service
representing the repository you
are upgrading to.
On UNIX and Linux, create the Preparing UNIX and Linux
new installation directory for hosts, page 35
the upgraded installation under
the $DOCUMENTUM/product
directory (the new
$DM_HOME directory).
On UNIX and Linux, modify Preparing UNIX and Linux
the DM_HOME variable in hosts, page 35
the installation owner’s .cshrc
or .profile file to point to
$DOCUMENTUM/product/
version_number.
On UNIX and Linux, modify Preparing UNIX and Linux
the library path variable in hosts, page 35
the installation owner’s .cshrc
or .profile file to point to the
location of the shared libraries
required by the server.
Determine the installation Setting up the installation installation owner username:
owner username and password owner account, page 33, __________
and consult the database
administrator. installation owner password:
__________
On UNIX and Linux, determine UNIX and Linux root password:
the root password documentation
__________
This is the operating system root
password. The root password
is required to complete the
upgrade.
Determine the names of the repository name:
repositories you are upgrading.
__________
Determine the Content Server Content Server version:
version from which you are __________
upgrading.
If you are upgrading from Upgrading from 5.x, page 87
5.x, ensure that one of the
repositories is designated as a
global registry.

Migrating the database to UTF–8

If the database was installed with a code page other than UTF-8 under a previous Content Server
version, you do not have to migrate the database to UTF-8 to upgrade the Content Server version.
However, to use Content Server’s multilingual functions, you need to migrate the database to UTF-8.
EMC Documentum supports upgrading repositories by using the existing database code page.
• On Oracle and Sybase, you can migrate existing repositories to Unicode using the tools supplied
by Oracle and Sybase. Contact Oracle or Sybase for any support you require in migrating the
database.
• On DB2, all repositories should have been created by using Unicode. They do not need to be
migrated. If the DB2 repository does not use Unicode, migrate the database by using IBM tools.
Contact IBM for any support you require.
• On SQL Server, you cannot migrate the database to Unicode.
The database_refresh_interval key

During Content Server installation or upgrade, the change checker process runs once per minute by
default. The process updates type caches as types are created or altered. Before you upgrade, ensure
that the key is set to 1 minute or delete it from the server.ini file.
Oracle optimization setting

To improve performance when upgrading large repositories for Content Servers that run with Oracle,
ensure that the optimizer mode (optimizer_mode in the init.ora file) is not set to ALL_ROWS.
Completing workflows before an upgrade

Before you shut down the repository for the upgrade, make sure that all workflows have completed
and do not submit any new workflows. To ensure that all workflows are completed, follow this
procedure:
1. Take the repository offline to prevent new workflows from being submitted.
2. Wait for all automatic tasks to complete.
Use the following DQL query to obtain the number of active automatic tasks in the repository:
select count(r_object_id) from dmi_workitem where
r_auto_method_id> '0000000000000000' and r_runtime_state in (0,1
If the query returns a nonzero value, active automatic tasks still need to be processed. If it returns
0, the repository contains no more active automatic tasks, and you can safely stop the repository.
If the query returns 0, run the query a few more times to ensure that no new automatic tasks
are being generated.

Upgrading sequence considerations

Consider the following upgrading sequence information before you begin upgrading Content Server:
• If you are using the data partitioning feature, which is new to version 6.5, you need to upgrade
the database first before you upgrade Content Server. If you are not using the data partitioning
feature, it does not matter which one you upgrade first.
• Do not probe log files before the entire upgrade is completed. Partial upgrade is not supported.
You need to upgrade the binaries, the connection broker, and the repositories are the same time.
• An upgrade from version 5.3.x to version 6.5 is supported without requiring any additional steps
aside from the standard upgrade procedure.
• For operating systems that do not support IPv6 in versions 5.3.x or 6 environments, you need to
upgrade the operating system first. You need to upgrade the following operating systems first if
they did not support IPv6 in versions prior to 6.5:
— Linux (Red Hat)
— Linux (SUSE)
— AIX
— Solaris
— HPUX
Note: Version 6.5 does not support IPv6 on the HPUX-IA operating system.
• If you are upgrading from version 5.3.x, 6, or 6 SP1 to version 6.5, the upgrade will not remove the
binaries of the Tomcat and WebLogic application servers. This is because Tomcat and Weblogic
are supported for client and UCF type applications, while JBoss is used for the Java method server.
Upgrading from 5.x

Upgrades to 6.x require a global registry. Therefore, if you are upgrading from 5.x to 6.x, you need
to verify that a 5.x repository is designated as a global registry.
To verify that a repository is designated as a global registry:

1. Using Documentum Administrator, log into the repository that should be the global registry,
using an administrator account.
2. In Classic view, in the left navigation tree, click the Administration node.
3. In the page that appears, under the heading "User Management", click Search for Users.
4. Search for the following user: “dm_bof_registry" (enter this value next to the User Name label,
and click Search).
5. View the properties of this user "dm_bof_registry" (click the (i) icon).
6. Make note of the user’s ’State’ and ’User Login Name’. If the user State is ’Inactive’, this repository
is not the global registry. To make this repository the global registry, follow the subsequent

procedures. If the global registry user is ’Active’, you need to verify some information in your
dfc.properties file on your application servers.
The following step enable you to verify the entries in the dfc.properties file.
7. From the application server machine, locate the dfc.properties file. Open this file in any text
editor. Ensure the following three attributes are set in the dfc.properties file:
• dfc.bof.registry.repository =
• dfc.bof.registry.username =
• dfc.bof.registry.password =
Without the above three entries, the global registry will not be set. If these entries are missing
or values are not complete, you need to add and populate these values. See the following
procedures for more details.
To enable a global registry:

1. Log into Documentum Administrator as an administrator in the repository where you want
to enable TBO/SBO functionality.
2. In Classic view, in the left navigation tree, click the Administration node.
3. In the page that appears, under the heading "User Management", click Search for Users.
4. Search for the following user: “dm_bof_registry" (enter this value next to the User Name label,
and click Search).
5. View the properties of this user "dm_bof_registry" (click the (i) icon). The properties page will
appear.
6. From the properties page, ensure the following options and values are set to the following:
• User State: Active
• User Source: Inline Password
• Restrict Folder Access: System
7. For security purposes, change the default password (make a note of the new password).
8. Click OK on the ’dm_bof_registry’ user ’Properties’ page
Upgrading the Content Server software

Use these instructions to upgrade Content Server software. The length of time needed to upgrade a
repository depends on the size of the repository. Allow sufficient time for backing up the repository
and performing the upgrade.
To upgrade the software installation:

1. Back up the repository.
2. If the repository contains customized repository formats (dm_format objects), back up the
customized formats.

Repository formats are upgraded by the dm_apply_formats.ebs script, which reads values from
the formats.csv file. If the attributes of a format in the repository do not match the format
descriptions in the formats.csv file, the script overwrites the existing values with the values
in the file.
3. Run the consistency checker.
The consistency checker is a script that looks for repository inconsistencies, such as users with
nonexistent groups, permissions sets with nonexistent users, and sysobjects that point to
nonexistent content files. Fixing inconsistencies in the repository improves the quality of the data
in the repository and results in a smoother upgrade. The syntax is:
dmbasic -fconsistency_checker.ebs -eEntry_Point -- repository_name
superuser password
• repository_name is the name of the repository against which you are running the consistency
checker.
• superuser is the username of a repository superuser
• password is the password for the superuser’s account.
The results of the consistency checker are directed to standard output.
4. Fix the inconsistencies reported by the consistency checker as errors.
The Content Server Administration Guide provides information on the consistency checker.
5. Disable all jobs.
• On Windows, disable jobs in all repositories on the host.
• On UNIX and Linux, disable jobs in all repositories in the installation you are upgrading.
6. For the upgrade on a Windows host, shut down the repositories and connection brokers.
a. Click Start > Programs > Documentum > Server Manager.
b. Select the correct Content Server and click Stop.
c. Click the connection broker tab.
d. Select each connection broker.
e. Click Stop.
7. For the upgrade on a UNIX or Linux host, shut down the repositories and connection brokers.
a. For each repository, run the dm_shutdown_repository script, where repository is the name of
the Content Server to be stopped.
b. Stop each connection broker using the dm_stop_connection broker utility.
The Content Server Administration Guide contains instructions.
8. Shut down the application server.
• To shut down the application server on Windows, stop the service called Documentum Java
method server. Ensure that the application server does not start automatically after a host
restart.
• To shut down the Java method server on UNIX or Linux, run the script
$DOCUMENTUM_SHARED/<application_server>/domains/DctDomain/stopMethodServer.sh.
9. Run the Content Server installation program.

contains details.
Note: Because of additional new features and functionality, installation of Content Server 6.5
takes approximately 50 percent more time than the installation of version 5.x.
10. Run the Content Server configuration program.
The Content Server configuration section in the installation chapter provides the procedure on
running the Content Server configuration program. Perform the procedure with the following
upgrade modification steps:
a. At step 6, select Custom configuration.
b. At step 8 (Configure a connection broker), select Upgrade an existing connection broker.
c. At step 9 (Configure a repository), select Upgrade an existing repository and skip to step 12.
The upgraded repository will use the same configuration settings as the existing repository.
If you are upgrading a repository on a Sybase platform, the upgrade procedure may hang
if the database transaction log is too small. When the repository is upgraded, it opens a
long-running transaction while the upgrade script is running. If the transaction log is too
small, the transaction hangs with locked system tables because the database server cannot
write information to the transaction log. To continue with the upgrade:
1. Run the following command on the Sybase database:
sp_dboption db_name,'trun log on chkpt',true
2. Run a checkpoint command to truncate the transaction log.

3. If steps 1 and 2 fail to resolve the issue and allow the upgrade to proceed, increase the
transaction log space.
11. After you complete the Content Server configuration, create a nonunique index on the
dm_sysobject.r_object_id and r_aspect_name properties by using the following MAKE_INDEX
command:
EXECUTE make_index WITH type_name='dm_sysobject',
attribute='r_aspect_name', use_col_id='T'
The inclusion of the use_col_id argument set to T automatically causes Content Server to include
the r_object_id column in the index.
12. If you are upgrading a repository in a distributed environment that uses a BOCS and
asynchronous write jobs, create an index on the dmr_content_s(i_parked_state, r_object_id)
properties. Use the following MAKE_INDEX command to do so:
EXECUTE make_index WITH type_name='dmr_content',
attribute='i_parked_state',use_col_id='T',id_in_front='F'
13. After the upgrade is complete, use the uninstaller program to clean up the method server instance
and the binaries on the older version from which you just upgrade. In a Windows environment
the uninstaller program is located at <Program Directory>\_uninst\weblogic. In a UNIX or Linux
environment the uninstaller program is located at $DOCUMENTUM_SHARED/_ininst/weblogic.

Using the update statistics tool

The Update Statistics tool generates current statistics for the RDBMS tables owned by the repository
owner. Generating statistics is always useful, particularly after you perform load operations or
if table key values in the underlying RDMBS tables are not normally distributed. When you are
upgrading Content Server from 5.3 to 6.x the performance will degrade significantly until you run the
update statistics tool on the database.
When you run the tool against an Oracle or Sybase database, the tool uses a file that contains
commands to tweak the database query optimizer. For Oracle, the file is named custom_oracle_stat.sql.
For Sybase, it is named custom_sybase_stat.sql. The file is stored in %DOCUMETNUM
%\dba\config\repository_name ($DOCUMETNUM /dba/config/repository_name). You can add
commands to this file. However, do so with care. Adding to this file affects query performance. If
you do add a command, you can use multiple lines, but each command must end with a semicolon
(;). You cannot insert comments into this file.
The -dbreindex argument controls whether the method also reorganizes database tables in addition
to computing statistics. For SQL Server and DB2, you can set the argument to either READ or FIX.
Setting it to READ generates a report on fragmented tables but does not fix them. Setting it to FIX
generates the report and fixes the tables. (In either case, the report is included in the overall job report.)
For Sybase, the -dbreindex argument is only effective if set to FIX, to reorganize the tables. Setting it
to READ does not generate a report on Sybase. If you include the -dbreindex argument set to FIX, the
repository owner (the account under which the tool runs) must have sa role privileges in the database.
The -dbreindex argument has no effect on a Oracle database.
The tool generates a report that is saved in the repository in System/Sysadmin/Reports/ UpdateStats.
The exact format of the report varies for each database.
The Update Statistics tool is installed in the active state, running once a week. Because this tool can be
CPU and disk-intensive, it is recommended that you run the tool during off hours for database use.
Consult with your RDBMS DBA to determine an optimal schedule for this tool.
Arguments
Table 10, page 91, lists the arguments for the tool.
Table 10. Update Statistics arguments
Argument Datatype Default Description

-dbreindex string READ Controls whether the tool actually
updates statistics or only reports on
RDBMS tables that need updating.
READ generates only the report.

This setting is valid only for SQL
Server and DB2 databases.
FIX generates the report and

updates the tables. This setting

Argument Datatype Default Description

is valid on SQL Server, DB2, and
Sybase databases. However, on
Sybase, it only fixes the tables. A
report is not generated.
This argument is not available for

Oracle databases.
-server_name string(32) - Name of the database server.
This is a required argument on

SQL Server and Sybase. It is set for
the job when the administration
tools are installed in repositories
running against a SQL Server or
Sybase database.
-queueperson string(32) - User who receives email and inbox
notifications from the tool. The
default is the user specified in the
operator_name property of the
server config object.
-window_interval integer 120 Execution window for the tool.
Refer to for a complete description.
Guidelines
Run this tool after you perform large loading operations.
When the job is run with -dbreindex set to READ and the statistics need updating, the report will say:
-dbreindex READ. If rows appear below, the corresponding
tables are fragmented.
Change to -dbreindex FIX and rerun if you want to reindex
these tables.
When the job is run with -dbreindex set to FIX, the report will say:
-dbreindex FIX. If rows appear below, the corresponding
tables have been reindexed.
Change to -dbreindex READ if you do not want to reindex
in the future.
Report sample
The Update Statistics report tells you when the tool was run and which tables were updated. The
report lists the update statistics commands that it runs in the order in which they are run. Here is a
sample of the report:
Update Statistics Report:

Date of Execution: 06-04-96
update statistics dmi_object_type

go
update statistics dm_type_s
go
update statistics dm_type_r
go
update statistics dm_type_r
go
update statistics dmi_index_s
go
. . .
End of Update Statistics Report
Adding descriptors to a global registry

If you are upgrading a repository to version 6.5 that is not the global registry, you first need to run a
script on the global registry that adds descriptors to the global registry. Descriptors are configuration
objects that the distributed content transfer system uses. The distributed content transfer system
includes UCF, ACS, BOCS, DMS, and part of DFC. You cannot modify these descriptors. You only
need to run this script once. If the repository you are upgrading is the global registry, you don’t
need to run this script.
To add the descriptors in a Windows environment run the following script:
%Documentum%\product\6.5\install\admin>dmbasic -f
dm_acs_install.ebs -e UpgradeDescriptors --
<repository name> <user name> <password>
Start upgrade of validation descriptors on docbase
<repository name>
Connected to docbase <repository name>
as user <user name>.
Successfully created a dm_validation_descriptor named
getpage_2.1 with version 2.1 with parameters 'filepath,cacheid,
basepath,mode,servername,objectid,format,pagenum,pagemod,timestamp,
command,page_plugin_name'
Successfully created a dm_validation_descriptor named move_2.1
with
version 2.1 with parameters 'filepath,cacheid,basepath,mode,
servername,objectid,format,pagenum,pagemod,timestamp,command,
content_objid'
Successfully created a dm_validation_descriptor named write_2.1
with version 2.1 with parameters 'mode,servername,docbaseid,
storeid,timestamp,command,formatid,content_objid,store_data,partition'
Successfully created a dm_validation_descriptor named park_2.1
with version 2.1 with parameters 'mode,servername,docbaseid,
storeid,timestamp,command,formatid,content_objid,store_data,partition'
store_2.1 with version 2.1 with parameters 'mode,servername,
docbaseid,storeid,timestamp,command,formatid,content_objid,
store_data,partition,parked_data_token,parked_fork_token'
write2_2.1 with version 2.1 with parameters 'mode,servername,
docbaseid,storeid,timestamp,command,formatid,content_objid,
store_data,partition,parked_data_token,parked_fork_token'
Successfully created a dm_validation_descriptor named read_2.1
with version 2.1 with parameters 'filepath,cacheid,basepath,
mode,servername,objectid,format,pagenum,pagemod,timestamp,command'

precache_2.1 with version 2.1 with parameters 'filepath,

cacheid,basepath,mode,servername,objectid,format,pagenum,
pagemod,timestamp,command'
Upgrade of dm_validation_descriptor data succeeded.
To add the descriptors in a UNIX environment run the following command:

$DOCUMENTUM/product/6.5/install/admin>dmbasic -f
dm_acs_install.ebs -e UpgradeDescriptors --
<repository name> <user name> <password>
The output of the script is the same as the output for Windows.
The descriptors might already exist if you run the script a second time for the same global registry, or
if the global registry is a 6.5 repository. If the descriptors already exist, the output from the script is:
%Documentum%\product\6.5\install\admin>dmbasic -f dm_acs_install.ebs
-e UpgradeDescriptors -- <repository name>
<user name> <password>
Start upgrade of validation descriptors on docbase
<repository name>
Connected to docbase <repository name> as
user <user name>.
Upgrade of dm_validation_descriptor data succeeded.

Chapter 7
Uninstalling Content Server
This chapter explains how to delete a repository or connection broker and how to uninstall an
existing Content Server installation. Do not uninstall an existing installation to upgrade to a new
Content Server release, because all upgrades based on an existing installation. Use the procedures in
this chapter only if you want to uninstall an existing Content Server, a repository and its contents, a
connection broker, or a Content Server software installation.
This chapter contains the following information:
• Order of uninstalling components, page 95
• Deleting a repository, page 96
• Deleting a connection broker, page 97
• Uninstalling the Content Server software, page 97
To delete a repository or connection broker or uninstall Content Server, you need to meet the
following requirements:
• Be able to log in as the installation owner
• Have sufficient database privileges to drop tablespaces or databases
Order of uninstalling components

Uninstall the software components in this order:
1. Shut down and uninstall the index agent if fulltext indexing is installed.
The Content Server Fulltext Indexing System Installation and Administration Guide provides
information about uninstalling fulltext indexing components.
2. Shut down the repository.
3. Shut down and uninstall the index server if fulltext indexing is installed. The repository must be
shut down for this.
4. Delete the repository.
5. Delete any connection broker located on the current host.
6. Uninstall the Content Server software.
7. Uninstall the Index Agent Configuration Program if fulltext indexing is installed.

Deleting a repository
Use these instructions to delete a repository.
To delete a repository you need to meet the following requirements:
• Be able to log in as the installation owner
• Have sufficient RDBMS privileges to drop tablespaces or databases.
Note: If the repository has a Content Transformation Services (CTS) product installed on it, you need
to uninstall the CTS product before deleting the repository. If you do not, the CTS product will not
be available in all other repositories.
To delete a repository:
1. Log in to the host as the Content Server installation owner.
• On Windows, click Start > Documentum > Server Manager, select the repository, and click
Delete.
• On UNIX and Linux, navigate to the $DM_HOME/install directory and run the
dm_launch_server_config_Program.sh program.
The Content Server configuration program starts.
3. Click Next.
4. On Windows, provide the installation owner password and click Next.
5. Select Custom Installation and click Next.
6. Select Create New, Upgrade, or Delete Repositories and click Next.
7. Select Delete an Existing Repository, select the repository to delete, and click Next.
You are asked if you want to delete the component.
8. Click OK.
The installer stops the Content Server and provides the location of the tablespace or database
deletion script.
This is $DOCUMENTUM/server_uninstall/delete_db/repository_name, where repository_name is
the name of the repository.
9. Click OK.
10. Indicate whether to configure another repository or exit from the configuration program and
click Next.
An information dialog box appears.
11. Click Finish.
12. From the database, drop the database tables associated with the repository.

Deleting a connection broker

Use these instructions to delete a connection broker.
Note: To delete a connection broker, you need to be able to log in to Windows as the installation
owner.
To delete a connection broker:

1. Connect to the host as the Content Server installation owner.
• On Windows, click Start > Documentum > Server Manager > Connection Broker, select the
connection broker, and click Delete.
• On UNIX and Linux, navigate to the $DM_HOME/install directory and run the
dm_launch_server_config_Program.sh program.
3. Click Next.
4. On Windows, provide the installation owner password and click Next.
5. Select Custom Installation and click Next.
6. Select Create New, Upgrade, or Delete Connection Brokers and click Next.
7. Select Delete an Existing Connection Broker, select the connection broker to delete, and click
Next.
8. When prompted to delete the component, click OK.
9. Indicate whether to configure another connection broker or exit from the configuration program
and click Next.
If you indicated to configure another connection broker, the program returns to the connection
broker dialog box, and you can repeat the connection broker deletion procedure. If you indicated
not to configure another connection broker, an information dialog box appears.
10. Click Finish.
Uninstalling the Content Server software

Use these instructions to uninstall the Content Server software from a host. You can only uninstall the
software after deleting all repositories and connection brokers in the installation.
To uninstall the Content Server software:

1. Delete all repositories and connection brokers in the installation.
Use the instructions in Deleting a repository, page 96 and Deleting a connection broker, page 97.
2. On Windows:
a. Click Start > Settings > Control Panel > Add/Remove Programs.
b. Select Documentum Content Server and click Remove.

c. Select Documentum Task Chaining Framework and click Remove.

d. Select Documentum Application Server and click Remove.
e. Select Documentum Service Wrapper and click Remove.
f. Optionally, uninstall the DFC Runtime Environment.
Note: Do not uninstall the DFC Runtime Environment if any other EMC Documentum
software is installed on the host.
3. On UNIX and Linux:
a. Navigate to the $DOCUMENTUM/_uninst/Server directory.
b. Run the Content Server uninstaller:
uninstaller.bin.
c. Navigate to $DOCUMENTUM_SHARED/tcf and uninstall the Documentum Task Chaining

Framework:
uninstaller.bin.
d. Navigate to $DOCUMENTUM_SHARED/jboss4.2.0/server and uninstall the application

server:
uninstaller.bin.
e. Navigate to $DOCUMENTUM_SHARED/serviceWrapper and uninstall the Documentum

service wrapper:
uninstaller.bin.
f. Optionally, navigate to $DOCUMENTUM_SHARED/_uninst/dfc and uninstall the DFC

Runtime Environment:
uninstall.bin
Note: Do not uninstall the DFC Runtime Environment if any other EMC Documentum
software is installed on the host.

Chapter 8
Installing Documentum Messaging
Services
The Documentum Messaging Services (DMS) component routes messages from web-based
applications and DFC to ACS servers and BOCS servers. Although part of the Content Server
product, DMS is installed by a separate installer script. You can install DMS on a separate host or on
the same host as the Content Server.
DMS is used in distributed environments. The Distributed Configuration Guide contains information on
the models for creating distributed environments and how DMS is used within those environments.
• Configuration requirements, page 99
• The dms.properties file, page 100
• Specifying the cleanup interval for expired messages, page 100
• Preinstallation requirements, page 101
• Installing DMS, page 101
• Uninstalling DMS, page 104
• Starting and stopping DMS, page 105
Configuration requirements
To use a DMS server:
• A dms_config object that represents the DMS server must reside in the global registry.
• A dms.properties file must be configured for the DMS server.
The installation process configures the dms.properties file automatically. Use Documentum
Administrator to set or change keys in the file.

Installing Documentum Messaging Services
The dms.properties file

The dms.properties file is created when you install DMS. With the exception of the key that defines
how long expired messages are held before removal from the DMS database, the properties in the file
are set to standard values that you should not change.
File administration
The file is administered by using JMX and accessed through the DMS resource agent in Documentum
Administrator. The resource agent is accessed through the Resource Management node. The
Documentum Administrator online help or the Documentum Administrator User Guide provide
instructions on accessing the resource agent.
If you want to connect to the DMS administration resource agent from outside of a firewall, you need
to configure the firewall settings to allow the RMI protocol for the port.
Changing the JMX user password

When you installed DMS, you provided a username and password for the JMX server. You can
change the password for that user.
To change the JMX user password:

1. Log in to Documentum Administrator as the installation owner.
2. Navigate to the DMS resource agent.
3. Double-click the resource agent to display the Mbeans in the agent.
4. Right-click the JmxUserManagementMBean and click Operations.
5. Click Change Password.
6. Type the current username and the new password.
7. Click Start Operation.
Specifying the cleanup interval for expired

messages
By default, expired messages are removed from the DMS database every 180 days. The number of
days between expiration and removal is set in the dms.properties file. You can change that interval.
To change the cleanup interval:

1. Log in to Documentum Administrator as the installation owner.
2. Navigate to the resource agent for DMS.
3. Use the agent to set the cleanup period.

Specify the number of days.
Preinstallation requirements
Before installing DMS, ensure that the following prerequisites are met:
• If you do not want to accept the defaults for directory locations or port numbers, have the chosen
directories and port numbers available.
Default directory locations are suggested for the installation directory, the user directory, and the
directory in which JMS messages are stored.
Default port numbers are suggested for the connection broker (1489 for a native connection
and 1490 for an SSL connection), application server instances (9080 for instance server), and
the database server (2638).
• A password for the dmsAdmin user is chosen.
The dmsAdmin user administers the DMS server’s dms.properties file through the resource
agent in Documentum Administrator.
• The DOCUMENTUM and DOCUMENTUM_SHARED environment variables are set.
Set $DOCUMENTUM to the installation directory. The installation owner must have read, write,
and execute permissions on this directory and its subdirectories.
Set $DOCUMENTUM_SHARED to the directory in which you want to install DFC on the DMS
host. This is also the top-level directory under which the scripts used to uninstall the components
are stored.
Installing DMS
Note: DMS and Content Server must be the same version even if DMS is installed on its own machine.
Use these instructions to install DMS.
To install DMS:
1. Download the compressed distribution file to a temporary location on the DMS server host.
2. Extract the file.
a. On Windows, double-click the file.
b. On UNIX and Linux, untar the file:
% tar -xvf filename
3. Start the installation program.

• On Windows, double-click the dmsWinSuiteSetup.exe file.
• On UNIX and Linux, type
% dmsoperatingsystemSuiteSetup.bin
and press Enter, where operatingsystem is the operating system on which you are installing.
The Setup program starts, and a Welcome dialog box appears.
4. Read the information in the dialog box, and click Next.
The installer verifies operating system requirements. The license agreement dialog box appears.
5. Accept the license terms and click Next.
The Directory for Documentum Software dialog box appears.
6. Specify the installation directory
• On Windows, navigate to the installation directory. The default is C:\Program
Files\Documentum. Then click Next. You can use Browse to select a different directory.
The Specify the user directory dialog box appears.
• On UNIX or Linux, type the path to the installation directory (default is
$DOCUMENTUM_SHARED/dms).
7. Specify the user directory, and click Next.
• On Windows, navigate to the user directory (default is C:\Documentum and click Next. The
Specify Primary Connection Broker Info dialog box appears.
• On UNIX or Linux, type the path to the user directory. The default is $DOCUMENTUM.
8. Define the connection broker information:
Note: DMS logs into the global registry only, so you need to specify the connection broker that
points to the global registry.
a. Type the connection broker name.
b. Optionally, type the connection broker port number.
The default port number for a native connection is 1489; the default port number for an SSL
connection is 1490. If you are using the default port number, ensure that the next port number
(1490) is available for use because the connection broker requires that two ports be reserved.
If you want to use numbers other than the default you need to create two entries in the
system’s network service table, one for a native connection and one for an SSL connection.
For example, for a connection broker named docbroker you need to add the following entries:
docbroker 8000/tcp #connection broker for native
connections
docbroker_s 8001/tcp #connection broker for secure
connections
On UNIX and Linux systems the network service table is located in /etc/services. On Windows
NT systems the network service table is located in /WINNT/system32/drivers/etc/services. At
installation time you are prompted only for the port number for the native connection. The
system will construct the port number for the SSL connection internally. The SSL connection
port number is always the native connection port number plus one.
c. Click Next.
The Enter Installation Owner Password dialog box appears.
Note: If you already have EMC Documentum software installed on the host, the DMS installation
program will skip this step because you specified the connection broker information with the
previous installation of EMC Documentum software.
9. Type the installation owner’s password, and click Next.
The password is validated when you click Next.

The Enter Database Server Information dialog box appears.
10. Specify the database server information:
a. To use a port number that differs from the default, type a port number.
b. Define a password for the embedded database’s administrative user.
c. Click Next.
The Enter Application Server Information dialog box appears.
11. Provide information for the application servers.
Two instances of the application servers are created, Admin Server and one to which DMS is
deployed.
a. Type a password for the application server user.
b. To use a port for the Administration Server that is different from the default, type a port
number for the Admin Server port. The default is 7001.
c. To use an instance port number that is different from the default, type a port number for the
instance port. This is the application server instance to which the DMS server is deployed.
The default is 9080.
d. Click Next.
The Specify directory location dialog box appears.
12. Specify the directory location for the JMS messages:
a. Accept the default location or type a different location.
The default location is C:\Documentum\dms\data (Windows) or userDirectory/dms/data/jms
(UNIX).
b. Click Next.
The Administration dialog box appears. This box displays the URL used by the administration
user, dmsAdmin, to create the resource agent needed to administer DMS in Documentum
Administrator.
13. Specify the password for the dmsAdmin user, and click Next.
The URL displayed in the Administration dialog box is the URL needed to create the resource
agent in Documentum Administrator for the DMS. The URL is also displayed on the Summary
dialog box and written to the install log file. Be sure to record that URL for use in Documentum
Administrator when creating the DMS resource agent.
A Summary dialog box appears that lists the components that will be installed, where each will
be installed, and the URL to use for administration resource agent.
14. Click Next to start the component installation.
Component installation begins, and a status dialog box appears to indicate progress. After all
components are installed, the Designate Global Registry dialog box appears.
15. Provide global registry information:
a. Type the name of the global registry.
b. Type the password for the global registry user (dm_bof_registry).
c. Click Next.
By default, the connection to the global registry is tested. If you do not want to test the connection,
clear the Test Connection check box.
A Starting Instance status dialog box appears. After the instance is started, a Finish dialog
box appears.
16. A dialog appears that show the post URL information. Click Next.
17. Click Finish.
18. Using Documentum Administrator, create a configuration object for DMS in the global registry.
Use the instructions in the online help for Documentum Administrator.
19. Optionally, create the resource agent for DMS in Documentum Administrator.
The DMS resource agent enables you to edit the dms.properties file to reset the expired message
cleanup interval. You need the URL created in Step 14.
The Documentum Administrator online help or the Documentum Administrator User Guide provide
instructions on creating a resource agent.
The post URL dialog box appears.
20. Note the information that appears in the post URL dialog box. If you plan on creating repository
objects for DMS, you will need this information. The post URL is used to contact the DMS to
deliver messages from DFC to DMS.
Uninstalling DMS
Uninstall all DMS components in the following order:
1. Documentum Messaging Server
2. Documentum Embedded Database
Note: This step prompts you for the database password before uninstalling the Documentum
Embedded Database.
3. Documentum Application Server
4. Documentum Service Wrapper
5. Documentum DFC Runtime Environment
On Windows hosts
Use the following uninstall procedure on a Windows host.
To uninstall DMS:
1. Log in to the DMS server host as the installation owner. This is the account used to install the
DMS server.
2. Use the Windows service to stop the DMS server. The service name is Documentum Messaging
Server.
3. Uninstall components in the order listed in the previous section:

a. Click Start > Settings > Control Panel > Add/Remove Programs
b. Select Documentum Messaging Services and click Change/Remove. The uninstaller starts
and a Welcome dialog box appears.
c. Click Next. An information dialog box indicates that the selected component will be
uninstalled and the directory from which the component will be removed.
d. Click Next. The selected component is uninstalled.
e. Select Documentum Embedded Database and click Remove.
f. Select Documentum Application Server and click Remove.
g. Select Documentum Service Wrapper and click Remove.
h. Select DFC runtime environment and click Remove.
i. Click Finish.
On UNIX and Linux hosts

Use the following uninstall procedure on UNIX and Linux hosts.
To uninstall DMS:
1. Log in to the DMS server host as the installation owner. This is the account used to install the
DMS server.
2. Uninstall each component in the order listed earlier in this section:
a. Navigate to $DOCUMENTUM_SHARED/_uninstall/component_name
b. Run the uninstall.bin script. A Welcome dialog box appears.
c. Click Next. An information dialog box indicates that the component will be uninstalled and
the directory from which it will be removed.
d. Click Next. The component is uninstalled.
e. Click Finish.
Starting and stopping DMS

Use these instructions to start and stop the DMS server, the database, and the application server.
On Windows hosts
DMS servers are installed as Windows services. To start and stop DMS servers, use the Services
dialog box. The service name is Documentum Messaging Server.
On UNIX and Linux hosts

Use the following procedures to start and stop DMS on UNIX and Linux hosts.
To start DMS:
1. Navigate to $DOCUMENTUM_SHARED/dms.
2. Run startDatabase.sh.
3. Navigate to $DOCUMENTUM_SHARED/jboss4.2.0/domains/DctmDomain.
4. Run startMethodServer.sh.
5. Run startDMS.sh.
Stop the application server after stopping DMS.
To stop DMS:
1. Navigate to $DOCUMENTUM_SHARED/jboss4.2.0/domains/DctmDomain.
2. Run stopDMS.sh.
3. Navigate to $DOCUMENTUM_SHARED/jboss4.2.0/domains/DctmDomain/bin.
4. Run stopMethodServer.sh.
5. Navigate to $DOCUMENTUM_SHARED/dms.
6. Run stopDatabase.sh.
Chapter 9
Installing Remote Content-File Servers
in Distributed or Load-Balanced
Configurations
This chapter provides instructions for installing and configuring content-file servers (remote Content
Servers) in distributed or load-balanced content configurations.
If you are creating a new single-repository in a distributed or load-balanced content configuration, a
configuration program separate from the Content Server configuration program is used for installing
content-file servers and creating the storage areas on the remote hosts and related location objects.
Review the Distributed Content Guide before you install a distributed configuration.
• Installing and configuring the content-file server, page 108
• Upgrading a distributed or load-balanced configuration, page 109
• Deleting a content-file server, page 112
The remote host must meet the same preinstallation requirements as the primary Content Server host.
The database client software must be installed on content-file server hosts. The content-file server
configuration program must connect to the database to properly create the following objects for
the remote server.
• server config
• acs config
• file store storage
• location
When a content-file server is created for a distributed or load-balanced content environment, the
server.ini file from the primary Content Server host is copied from the primary host to the remote
host. The values used on the primary and remote hosts for database connectivity must be identical to
ensure that the value of the database_conn key on the primary Content Server host is valid on the
Installing Remote Content-File Servers in Distributed or Load-Balanced Configurations
remote hosts. For example, if the database is SQL Server, ensure that the DSN name for the SQL
Server instance’s ODBC data source is the same on all hosts.
All hosts in a distributed or load-balanced configuration must be set to the same UTC time.
A repository that uses a distributed or load-balanced storage area with encrypted file stores as
components cannot use shared content.
EMC Documentum Web Publisher and EMC Documentum Site Caching Services are not supported
in distributed or load-balanced configurations, in federations, or where replication is used.
Caution: After a repository has been configured to use distributed or load-balanced storage, it is
not possible to revert to using nondistributed storage.
Note: If the Content Server file store is assigned to a shared folder on the network with a UNC path,
you need to meet the following requirements:
• Content Server and the file store need to be on the same domain
• The installation user account of Content Server needs to be available on the domain.
• The installation user account needs to have full access control for the file store.
Installing and configuring the content-file

server
Use these instructions to install and configure the content-file server.
To configure the content-file server:

1. Copy the Content Server installation files from the installation media to the correct directories
on the host.
This step is identical to the process used to copy files onto the primary Content Server host. The
Content Server installation sections in the Content server installation chapter provide instructions.
2. Start the content-file server configuration program.
• On Windows, the configuration program starts automatically following a reboot of the host.
If the configuration program does not start automatically, or if you have to delete the
content-file server and need to reconfigure the content-file server, do the following:
— Navigate to %DM_HOME%\install.
— Double-click cfsConfigurationProgram.exe.
• On UNIX or Linux, navigate to $DM_HOME/install and type:
%dm_launch_cfs_server_config_program.sh
A Welcome dialog box appears.

3. Click Next.
On Windows, the Installation Owner Password dialog box appears.
On UNIX or Linux skip to Step 5.
4. On Windows, type the installation owner’s password and click Next.

5. Type the hostname of the primary connection broker for the repository and verify or type the port
number on which the connection broker listens and click Next.
The port defaults to 1489. If you are using the default port number, ensure that the next port
number (1490) is available for use because the connection broker requires that two ports be
reserved.
6. Select the repository for which you are installing the content-file server, type the username and
password for a superuser in that repository and click Next.
The repository list is populated with repositories known to the connection broker for which you
provided information in the previous step. The superuser name defaults to the Documentum
installation owner’s name.
7. Type the name and port number for the connection broker on the current host, indicate whether
connection broker startup following a system restart is automatic or manual, and click Next.
The default values are Docbroker and 1489. If you are using the default port number, ensure that
the next port number (1490) is available for use because the connection broker requires that two
ports be reserved. The connection broker is started.
8. Accept the default location of the data directory or browse to a different location and click Next.
The data directory is where content files are stored in the repository.
9. Accept the default location of the share directory or browse to a different location and click Next.
The share directory is where clients, example code, and required libraries are stored.
10. Accept the default service name for the new content-file server or type a different name click Next.
11. Click Finish.
The content-file server is configured and running.
12. To start the application server instance that is running the Java method server and Content
Server, do one of the following:
• On Windows hosts, restart after the installation.
• On UNIX or Linux distributed or load-balanced configurations, use Documentum
Administrator to set the Get method for each component of the distributed or load-balanced
store to Surrogate Get.
Upgrading a distributed or load-balanced

configuration
This section describes the overall procedure for upgrading an existing distributed or load-balanced
configuration.
Use these guidelines in deciding how to upgrade a distributed or load-balanced configuration.
• Repository federations
EMC Documentum supports federations that contain repositories of different versions. In this
release, any mix of version 5.1 and later repositories may be federation members. If you are
upgrading the repositories in a federation, upgrade the governing repository first.
If the governing repository is a version 5.3 or 5.3 SP1 repository, keep in mind the following:
— Prior versions do not support dynamic groups. Consequently, any dynamic groups defined
in the governing repository are propagated to any members prior to version 5.3 as standard,
nondynamic groups.
— Similarly, prior versions do not support access restricting (AccessRestriction,
ExtendedRestriction) entries in ACLs. If the federation’s federation mode is replicating ACLs
with those kinds of entries to member repositories prior to version 5.3, the entries are ignored
by Content Servers prior to version 5.3.
— The restricted_folder_ids attribute for users (introduced in version 5.3) is a local attribute. This
means that any restricted users in the governing repository are propagated as unrestricted
users in the member repositories. If the member is a version 5.3 or 5.3 SP1 repository, you can
set that attribute locally.
• Repositories with distributed or load-balanced content
Shut down the primary Content Server and all content-file servers. Upgrade the primary Content
Server first, then upgrade the content-file servers.
You cannot use the cfsConfig program, which is used for creating content-file server, to upgrade
content-file servers prior to version 5.3 SP1.
• Repositories with object replication
Upgrade the source repository, then the target repositories. If you have a group of repositories
where each repository is both a source and a target, the upgrade can begin with any of the
repositories. This can apply, for example, if objects are replicated from repository A to repository
B, repository B to repository C, and from repository C to repository A.
You can replicate between repositories that use different Content Server versions, but you lose
attributes that are in the newer version, since they cannot be replicated to a version that does
not contain them. Content Server version 6.5 supports replication among server versions 5.1
and later only.
If you are upgrading a distributed or load-balanced configuration on Windows, do not reboot the
remote hosts by using Terminal Services. Reboot the remote hosts directly from those hosts.
To upgrade a distributed or load-balanced configuration:

1. On the primary host, use the instructions in Upgrading the Content Server software, page 88, to
upgrade Content Server, connection brokers, and repository.
2. On each remote host, use the instructions in Upgrading the Content Server software, page 88,
to upgrade Content Server, but cancel the process before running the repository configuration
scripts.
3. Create an acs config object in the repository for the ACS server installed with each content-file
server.
For example, if there are three content-file servers, you need to create three acs config objects.
a. On the content-file server host, navigate to $DM_HOME/install/admin (UNIX or Linux) or
%DM_HOME%\install\admin (Windows).
b. Run the dm_acs_install.ebs script:
dmbasic -f dm_acs_install.ebs -e Install -- repository_

name user_name password acs_name server_config_name Java_
method_server_port acs_protocol
The parameters are described in Table 11, page 111. The acs config object is created in server
config mode and uses the network locations, connection broker projection targets, and stores
from the associated server config object. If you need to change the mode to acs config mode,
in which you manually set network locations, connection broker projection targets, and
stores, use Documentum Administrator to change the mode and create the manual settings.
Do not manually modify the new acs config object by using the API or DQL.
Table 11. Parameters required by dm_acs_install.ebs script
Parameter Description and values

repository_name Name of the repository served by the
content-file server and its ACS server, where
the acs config object is being created.
user_name Username of a user with superuser
privileges, for example, the installation
owner.
password Password for the superuser account.
acs_name Object name of the acs config object you are
creating. This may be any arbitrary name,
but the name must be unique among the
object names of acs config objects and the
server config objects of both the primary
Content Server and any content-file server.
server_config_name Object name of the server config object of
the content-file server.
Java_method_server_port Port where the application server on the
content-file server host listens, which
was provided during content-file server
installation
acs_protocol Communication protocol used by the ACS
server. Valid values are http and https.
4. If the content-file servers are installed in a different file-system path from the primary Content
Server, create new site-specific location objects for locations that are new in the upgraded
repository.
a. Connect to the repository by using Documentum Administrator.
b. Create site-specific dm_dba and auth_plugin location objects that contain the locations on
each of the remote sites of the dba directory ($DOCUMENTUM/dba on UNIX or Linux;
%DOCUMENTUM%\dba on Windows) and the authentication plugin.
c. In the server config object for the content-file server, set the auth_plugin_location and
dba_location to the location objects you just created.
5. Start the application server.
Deleting a content-file server

Use these instructions to delete a content-file server and its software installation in a distributed or
load-balanced content environment. These instructions delete only the content-file server. They do
not delete the repository or affect the primary Content Server for the repository.
To delete the content-file server, you need to be able to log in as the installation owner. On Windows,
do not use the Server Manager program to uninstall the server. It launches the configuration program
for primary Content Servers, not content-file servers.
Before you delete the software installation, also delete any connection brokers on the host. Use the
instructions in Deleting a connection broker, page 97.
To delete a content-file server:

1. Log in to the host as the Content Server installation owner.
2. Navigate to the $DM_HOME/install directory (UNIX or Linux) or %DM_HOME%\install folder
(Windows).
3. Start the content-file server configuration program.
• On Windows, double-click cfsConfigurationProgram.exe.
• On UNIX or Linux, navigate to $DM_HOME/install and type:
%dm_launch_cfs_server_config_program.sh
A Welcome dialog box appears.

4. Click Next.
5. On Windows, type the installation owner’s password and click Next.
6. Select Delete Content-File Server and click Next.
7. Type the installation owner’s name and password and click Next.
The service is deleted.
8. Click Finish.
To delete the server software installation from the remote host:

1. Navigate to $DOCUMENTUM/_uninst/Server (UNIX or Linux) or %Documentum%\_
uninst\Server (Windows)
2. Run the server uninstaller:
• On Windows, double-click uninstall.exe.
• On UNIX, type:
uninstaller.bin.
Chapter 10
Installing Content Server with Microsoft
Cluster Services
This chapter describes how to install and configure Content Server to provide failover support under
Microsoft Cluster Services. This chapter contains the following information:
• Overview, page 115
• Choosing a configuration, page 116
• Configuring an active/passive cluster, page 118
• Configuring an active/active cluster, page 127
• Upgrading Content Server installed with Cluster Services, page 130
Overview
Microsoft Cluster Services supports the following forms of clustering:
• Active/passive clusters
In active/passive clustering, the cluster includes active nodes and passive nodes. The passive
nodes are on standby and are only used if an active node fails. In active/passive clusters, both
nodes support the same repository.
• Active/active clusters
In active/active clusters, all nodes are active. One node is considered the primary node, and the
other node is considered the secondary node. If one node fails or is taken offline, the remaining
node takes on the additional processing operations. In active/active clusters, each node supports a
different repository.
In a cluster environment, every service that the cluster runs uses resources of the cluster node. Every
service has its own resources, such as hard drive, IP address, and network name, assigned to it. All
resources that a clustered service uses form a resource group. The connection broker and Content
Server are a part of this resource group. In a cluster, all resources form a virtual server that can move
from one physical server to another to provide failover support.
Installing Content Server with Microsoft Cluster Services
Choosing a configuration
A Content Server installation supports two types of cluster service configurations:
• active/passive
• active/active
This chapter provides detailed installation instructions for both configurations. Choose the
configuration based on available hardware and your organization’s business needs. Figure 8, page
116 illustrates Content Server and connection broker setup in an active/passive cluster.
Figure 8. Active/passive cluster
In an active/passive configuration, both nodes support the same repository. Content Server and
connection broker run on the primary node. If the primary node fails, the secondary node that was on
standby takes ownership of the resource group. After the cluster resources are brought online on the
secondary node, the connection broker and Content Server start on the secondary mode.
In an active/active configuration, each node supports a different repository. Each node is considered
the standby to the other node. Each node owns its own resource group. Each resource group has
its own virtual IP address, a virtual hostname, shared disk, connection broker, and Content Server.
Figure 9, page 117 illustrates Content Server and connection broker setup in an active/active cluster.
Figure 9. Active/active cluster
If a node fails or is taken offline, its resource group is moved to the remaining node in the cluster.
The remaining node then manages two resource groups. When the failed node is running again, the
cluster administrator can move one resource group back.
Before you install and configure Content Server and a repository under Microsoft Cluster Services,
read Chapter 2, Preparing the Host for Content Server Installation, and perform the preinstallation
tasks described there. Complete the checklist in Installation and configuration checklist, page 55.
Whether you are configuring an active/passive cluster or an active/active cluster, set up the shared
disks to be used by the repositories. Ensure that the shared disks include a directory to use for
content storage.
If you are configuring an active/active cluster, the user who configures Microsoft Cluster Services
must have read and write permissions on both nodes on the directories where the connection broker
logs reside.
Note: Fulltext indexing and Documentum Site Caching Services are not supported in installations
that use Cluster Services.
Configuring an active/passive cluster

Follow these procedures to configure an active/passive cluster and install servers and a Content
Server. Complete all procedures in the sections that follow in the order in which they are listed:
• Creating the cluster resource group, page 118
• Installing Content Server software on the nodes, page 119
• Configuring Content Server, page 119
• Configuring the connection brokers, page 124
• Creating additional cluster resources, page 125
• Verifying failover, page 126
Creating the cluster resource group

Use this procedure to set up the cluster resource group.
To create the cluster resource group:

1. Use the MSCS Cluster Administrator utility to create a cluster resource group that contains the
following resources:
• A virtual IP address
Content Server uses this IP address. Other products can share the IP address because the
connection broker and Content Server only listen on particular ports.
• A virtual network hostname
The virtual network hostname is for the virtual IP address.
• A shared disk partition
This is the location of the repository data directory, where content files are located.
2. Move the resource group between the primary and standby hosts to ensure that the virtual IP
address, virtual network hostname, and shared disk partition fail over properly.
a. In the Cluster Administrator, right-click the cluster group name.
b. Click Move Group.
The resource group is toggled between the hosts and the owner name changes.
3. Ensure that the first node owns the resource cluster group.
Installing Content Server software on the nodes

The first part of the installation process copies files from the installation media to the hard disk. On
each of the two nodes, copy the files from the installation media to create a Content Server installation
on each node. Use the same drive letter on each node for the installation.
Configuring Content Server

The second part of the installation involves configuring Content Server and its associated connection
broker, which includes configuring them for Microsoft Cluster Services.
To configure Content Server

Log in to Windows as the installation owner, navigate to the DM_HOME\install directory, and
launch Server_Configuration_Program.exe.
2. Click Next.
4. If you did not enable Trusted Content Services during installation, optionally select the check box
and type the Trusted Content Services license key and click Next.
5. If you did not enable Content Services for EMC Centera during installation, optionally select the
check box and type the license key and click Next.
6. Click Custom Configuration and click Next.
7. Select to configure a connection broker and a repository, and click Next.
connection broker listens, or accept the defaults. The default port is 1489. If you are using the
default port number, ensure that the next port number (1490) is available for use because
the connection broker requires that two ports be reserved.
d. Click Next. The connection broker is started.
Note: Do not configure additional connection brokers on this host.
e. Click Next.
f. To continue to configuring a repository, select Continue with server configuration and
click Next.
9. Select Create a repository and click Next.

a. To enable Content Storage Services in the repository, select the check box, type the license
b. To enable Retention Policy Services in the repository, select the check box, type the license
c. To enable Federated Records Services in the repository, select the check box, type the license
d. To enable Records Manager in the repository, select the check box, type the license key,
and click Next.
e. To enable Physical Records Manager in the repository, select the check box, type the license
The Data Directory dialog box appears.
f. Click Next to accept the default data directory location or browse for a new location.
The data directory is the location where content files are stored. Do not choose a directory
that is used by another repository for content file storage or any other purpose.
g. Click Next to accept the default share directory location or browse for a new location.
variable. This environment variable sets the directory into which EMC Documentum
Foundation Classes and other components are installed.
h. Type the directory where the database client software is installed and click Next. If the
configuration program cannot locate the database client software required to connect to the
database, it asks you to identify the directory that contains the software.
i. Type the name of the repository. Name and ID to assign to the repository, page 23 contains
Note: If you are installing on the second node, use the same repository name you used for
the first node.
j. Type the repository ID. Name and ID to assign to the repository, page 23 contains information
about repository ID requirements.
Note: If you are installing on the second node, use the same repository ID you used for
the first node.
k. Type a description for the repository.
l. Select the repository size.
m. Select the authentication domain.
n. Indicate whether Content server starts automatically or manually. Check Automatic to
start Content Server automatically when the host starts or Manual to start Content Server
manually.
o. Click Next.
10. Type connection broker connection information for the connection broker to which you want
the repository to broadcast its connection information. Express configuration broadcasts to
the default local connection broker
a. Type the connection broker port number.
The port number is the port where the connection broker listens. The fault port number is
1489. If you are using the default port number, ensure that the next port number (1490) is
available for use because the connection broker requires that two ports be reserved.
b. Type the connection broker hostname and click Next.
c. Click Test connection broker to test the connection broker.
11. Select the mode in which client applications connect to the repository.
• Select Native for unsecure connections.
12. Click Next.
13. If you are installing on the first node, select Create a new database user account, then provide
database information.
a. Choose the correct database connection for your database instance from the drop-down list.
d. Type the database administrator’s username and password.
e. Click Next.
f. Accept the default paths and sizes for database storage or change them and click Next.
g. Edit or accept the default database scripts.
Edit Script. When you have saved the file, click Next.
14. If you are configuring the second node, chose Use an existing database account and provide
database information.
a. Choose the correct database connection for the database instance from the drop-down list.
Use the account you created for the first node. This user is the repository owner.
d. Click Next.
e. Choose the correct index tablespace or datafile name.
f. Click Next.
15. Accept or modify Content Server initialization values. Express configuration uses the default
initialization file.
repository tables.
file, click Next.
16. Set the following parameters in the %DOCUMENTUM\dba\config\<repository_name>\server.
ini file:
• [SERVER_STARTUP] server_config_name = <repository_name>
• [DOCBROKER_PROJECTION_TARGET] proximity = 20
• [DOCBROKER_PROJECTION_TARGET1] proximity = 200host = <machineA> port = 1489
17. If you are installing on the second node, transfer the aek.key file from the first to the second node:
a. On the second node, delete the %DOCUMENTUM%\dba\secure\aek.key file.
b. Copy the %DOCUMENTUM%\dba\secure\aek.key file from the first node to the same
location on the second node.
c. On the second node, navigate to %DM_HOME\bin.
d. Open a command line and run this command: dm_encrypt_password -docbase
repository_name -rdbms -encrypt database_password
18. Re-encrypt the database password with the new aek.key as follows: dm_encrypt_password
—docbase <repository_name> —rdbms —encrypt <password>.
19. If you are installing on the second node, click Cancel and exit the installation program.
20. Provide the SMTP server information. The SMTP server is used to send email notifications to
the installation owner and repository users.
a. Type the name or IP address of a computer on the network that hosts an SMTP server.
The computer can be a remote host or the computer that hosts Content Server. All UNIX
operating systems and Windows 2000 Server include an SMTP server.
b. Type the installation owner’s email address.
c. Click Next.
21. Decide whether to designate the current repository as a global registry.
connection broker.
23. Accept or modify the repository configuration scripts. Express configuration runs the scripts
without modification.
the repository.
24. Click Next.
26. If you are installing on the first node, select Repository Headstart and click Edit Script.
27. Modify the Repository Headstart script to point to the location object of the shared drive on
which the repository resides.
a. Locate these lines:
status=dmAPISet("set,c,l,file_system_path", dataHome &
Basic.PathSeparator$ _ & docbaseName &
Basic.PathSeparator$ & "content_storage_01")
Modify the Repository Headstart script to point to the location object of the shared.
drive_letter:\documentum\data\repositoryname\content_storage_01") drive_letter is the
shared drive where the repository data directory resides. repositoryname is the name of
the repository.
b. Change them to
status=dmAPISet("set,c,l,file_system_path",
"drive_letter:\documentum\data\
repositoryname\content_storage_01")
drive_letter is the shared drive where the repository data directory resides.
repositoryname is the name of the repository.
Example:
E:\documentum\data\repository1\content_storage_01
28. Run the default scripts unless you are familiar with the internal configuration of Content Server.
• To run the default repository configuration scripts, click Next.
• To edit additional repository configuration scripts, select the script and click Edit. Click Next
after you edit and save any of the scripts.
The scripts run and the repository is configured.
29. Click Finish.
30. Once you have finished setting up the two nodes against the cluster, confirm the virtual host
name. 2. 3. 4. 5. 6.
31. Disable clustering by changing the host name of one of the nodes to the virtual host name.
32. Run the hotfix pkiD6ChangeId.bat of Bug147071_pre60SP1_engr_fix.
33. Confirm that the connection broker and Content Server launch correctly with the fix.
34. Change node’s virtual host name back to the original host name, and verify that it launches
correctly.
35. Repeat step 31, step 32 and step 34 until all nodes have new tickets.
36. Shut down Content Server and the connection broker.
37. Move the cluster group to the second node.
38. Use the instructions in Installing Content Server software on the nodes, page 119, and
Configuring Content Server, page 119, to repeat the installation and configuration procedures
for the second node.
39. To start the application server instance that is running the Java method server and ACS server,
restart the Windows hosts after the installation is completed.
Configuring the connection brokers

You need to configure the connection brokers on both nodes to listen on the virtual network host.
To configure the connection brokers:

1. Start Server Manager by clicking Start > Programs > Documentum > Documentum Server
Manager.
2. Click Docbroker, then click Edit Service.
3. Add the following line to the service command:
-host virtual_network_host_name
For example, if the virtual network hostname is dmcluster1:
-host dmcluster1
4. Click OK.
5. Highlight repository and click Edit server.ini.
6. Edit the connection broker_DOCBROKER section of the server.ini file:
[connection broker_DOCBROKER]
host=virtual_network_host_name
For example:
host = dmcluster1
7. Save the server.ini file.

8. Navigate to C:\Documentum\config and open the dfc.properties file in a text editor.
9. Edit the connection broker_PRIMARY section of the dfc.properties file:
For example:
host = dmcluster1
10. Save the dfc.properties file.

11. Repeat this procedure on the other node.
Creating additional cluster resources

Use these procedures to create cluster resources for the connection broker and Content Server.
Perform the procedures only on the node that presently owns the existing resource group.
Note: Be sure to perform both procedures.
To create the connection broker cluster resource:

1. Open the Cluster Administrator utility.
2. Highlight the name of the existing cluster group, for example, dmgroup1.
3. Click File > New > Resource.
4. In the Name field, type connection broker.
5. In the Resource Type field, select Generic Service.
6. Click Next.
7. In the Possible Owners dialog box, ensure that both nodes are in the Possible Owners list box
and click Next.
8. Move the virtual network hostname from the Available Resources list box to the Resource
Dependencies list box and click Next.
9. Type the connection broker service name and click Use Network Name as Computer Name.
To locate the connection broker service name, click Start > Administrative Tools > Services and
double-click Documentum connection broker Service connection broker. The Service Name
field value is the connection broker service name.
10. Click Next.
11. Click Finish, then click OK.
12. Highlight connection broker and select File > Bring Online.
To create the Content Server cluster resource:

1. Open the Cluster Administrator utility.
2. Highlight the name of the existing cluster group.
3. Click File > New > Resource.
4. In the Name field, type repository_nameDocbase.
For example, if the repository name is theodora, type theodoraDocbase.
6. Click Next.
7. In the Possible Owners dialog box, ensure that both nodes are in the Possible Owners list box
and click Next.
8. Move the shared disk partition, virtual network name, and connection broker from the Available
Resources list box to the Resource Dependencies list box, then click Next.
9. Type the service name.
dmServerrepository_name
10. Click Use Network Name as Computer Name.

11. Click Next.
12. Click Finish, then click OK.
13. Bring the Content Server generic service resource on line by highlighting repository_nameDocbase
and selecting File > Bring Online.
Verifying failover
After you complete the preceding procedures, verify that failover works properly.
To verify failover:
1. On a client computer, ensure that the dfc.properties entries refer to the virtual network hostname
or virtual IP address.
2. Connect to the repository from the client computer.
3. Start the Cluster Administrator utility.
4. Move the resource group from the node where it is running to the other node.
5. After the resource group comes online on the other node, verify that the client can run queries.
Configuring an active/active cluster

In an active/active cluster, each node initially has its own repository and Content Server. You create
two cluster resource groups, and each node owns one. If a Content Server fails on one node, a second
Content Server starts on the second node to keep the repository on the first node running.
Each cluster resource group has the following:
• virtual IP address
• virtual network hostname
• one shared disk drive (where the repository resides)
• one connection broker
• one Content Server
To configure an active/active cluster, complete the procedures in the following sections in the order in
which they are listed:
• Creating the first cluster resource group, page 127
• Installing Content Server software on the hosts, page 128
• Configuring Content Server on the first and second nodes, page 128
• Configuring the second cluster resource group, page 128
• Modifying server.ini and dfc.properties, page 128
• Creating the connection broker generic service resource, page 129
• Creating the Content Server service resource, page 129
• Verifying failover, page 130
Creating the first cluster resource group

Create the first cluster resource group by following the instructions in Creating the cluster resource
group, page 118.
Installing Content Server software on the hosts

On each of the two nodes, copy the files from the installation media to create an Content Server
installation on each node. contains instructions.
Note: Use the same drive letter on each node.
Configuring Content Server on the first and second

nodes
In an active/active configuration configure a Content Server on each of the two nodes. The procedure
for configuring Content Server in an active/active cluster is the same as configuring Content server in
an active/passive cluster. Follow the instructions in Configuring Content Server, page 119 on the first
and the second node in the cluster.
Configuring the second cluster resource group

Create the second cluster resource group by following the instructions in Creating the cluster
resource group, page 118.
Modifying server.ini and dfc.properties

You might want to edit server.ini and dfc.properties on both nodes to ensure that each repository
projects to the connection brokers on the two nodes.
In the following examples, assume that the virtual network hosts for the two cluster resource groups
are called dmcluster1 and dmcluster2. It does not matter which cluster resource group is primary
and which is backup.
Edit all four of the server.ini files so that they read as follows:
dfc.docbroker.host[0]=dmcluster1
dfc.docbroker.host[1]=dmcluster2
Edit the two dfc.properties files so that they read as follows:
[connection broker_PRIMARY]
host=dmcluster1
[connection broker_BACKUP_0]
host=dmcluster2
Creating the connection broker generic service

resource
Configure the second connection broker as a generic service resource for the second resource group.
To create the connection broker generic service resource:

1. On both hosts, ensure that the user who configured the cluster has read and write permission on
the directory where connection broker logs are stored.
This is typically drive:\documentum\dba\log.
2. On the node that currently owns the second resource group, open the Cluster Administrator
utility.
3. Highlight the name of the second resource group and select File > New > Resource.
4. In the Name field, type ConnectionBroker2.
6. Click Next.
7. Ensure that both nodes are listed in the Possible Owners list box and click Next.
8. Move the virtual network hostname from the Available Resources list box to the Resource
Dependencies list box and click Next.
9. Type the following on the command line, substituting the driver letter where the Content Server
is installed for drive and the virtual network hostname for the second cluster resource group for
virtual_network_hostname:
drive:\documentum\product\6.5\bin\dmconnection broker.exe
-host virtual_network_hostname
-logfile drive:\documentum\dba\log\connection broker2.log
10. Type drive:\documentum in the Current Directory field.

11. Click Use Network Name as Computer Name and click Next.
12. Click Finish, then OK.
13. Highlight the cluster resource ConnectionBroker2 and click File > Bring Online.
Creating the Content Server service resource

You need to create a service resource for Content Server on the node that owns the second resource
group.
To create the Content Server service resource:

1. On the node that owns the second resource group, open the Cluster Administrator utility.
2. Highlight the name of the second resource group and select File > New > Resource.
3. In the Name field, type repository_nameDocbase.

5. Click Next.
6. Ensure that both nodes are listed in the Possible Owners list box and click Next.
7. Move the shared disk partition, virtual network name and connection broker2 from the Available
Resources list box to the Resource Dependencies list box and click Next.
8. Type dmServerrepository_name as the service name.
9. Click Use Network Name as Computer Nameand click Next.
10. Click Finish, then OK.
11. Highlight the cluster resource repository_nameDocbase and click File > Bring Online.
Verifying failover
After you complete the preceding procedures, verify that failover works properly.
To verify failover:
1. On a client computer, ensure that the dfc.properties entries refer to both virtual network
hostname or virtual IP address.
2. Connect to both repositories from the client computer.
3. Start the Cluster Administrator utility.
4. Move the two resource groups back and forth between the nodes.
5. After a resource group comes online on a new node, verify that the client can run queries.
Upgrading Content Server installed with

Cluster Services
Use the following general procedure to upgrade Content Server installed with Microsoft Cluster
Services. This procedure applies to upgrades on active/passive, active/active, single-repository,
and multirepository configurations.
To upgrade an active/passive, single-repository cluster:

1. Shut down the Content Servers on both nodes.
This shuts down the repository.
2. Shut down both hosts.
3. Restart the first node.
Do not restart the Content Server on the first node.
4. On the first node, upgrade Content Server software.
Use the instructions in Upgrading the Content Server software, page 88.
5. Upgrade and configure the repository and connection broker.

6. Open the Services dialog box and verify that the application server was created correctly.
If the Documentum Java method server is started, it was created correctly.
7. Test the repository to verify that it is functioning correctly.
8. Shut down the repository on the first node.
9. Shut down the first node.
10. Start the second node.
11. Start the connection broker on the second node.
12. Upgrade Content Server software on the second node.
Use the instructions in Upgrading the Content Server software, page 88.
13. Start the configuration program and select Custom Configuration.
14. Select Upgrade and the repository to upgrade.
15. When the configuration program reaches the panel on which scripts are run, click Cancel.
Do not run the scripts. The application server is created and the repository is upgraded.
16. To start the application server instance that is running the Java method server and ACS server,
restart the Windows hosts after the upgrade is completed.
Chapter 11
Configuring Multiple Content Servers
on a Single Host for a Particular
Repository
You can run multiple Content Servers on a single host against a particular repository. This chapter
provides instructions for creating such a configuration.
• Windows hosts, page 133
• UNIX hosts, page 135
Windows hosts
Use these instructions after a repository is configured to create additional servers for that repository
on the repository host. The Content Server Administration Guide provides instructions on configuring
additional servers for a repository on remote hosts
To configure additional servers on a Windows host:

1. Connect to the repository as a superuser by using Documentum Administrator and create a new
server config object by saving the object with a new object name.
For example, if the existing server config object is called caruso, call the new server config
object caruso1.
In Documentum Administrator, navigate to Administration > Basic Configuration. From the File
menu, select Save As... and save the config object with a new name.
2. Disconnect from the repository.
3. Create a server.ini file for the new Content Server.
a. On the Content Server host file system, navigate to the
%DOCUMENTUM%\dba\config\repository_name directory, where repository_name is the
name of the repository.
b. Create a copy of the server.ini file called server1.ini.
c. Open the server1.ini file and add these lines:
service=caruso1
Configuring Multiple Content Servers on a Single Host for a Particular Repository
server_config_name=caruso1
These values must match the entries in the \Winnt\System32\drivers\etc\ file.
d. Save the server1.ini file.
4. Navigate to the \Winnt\System32\drivers\etc\ and open the services file in a text editor.
5. Assign port numbers to the new Content Server.
For example, if these entries exist for the primary Content Server
dm_caruso 10000/tcp # repository service caruso
dm_caruso_s 10001/tcp # repository secure service
Add the following entries for the new Content Server:
dm_caruso1 10005/tcp # repository service caruso1
dm_caruso1_s 10006/tcp # repository secure service
6. Save the services file.

7. Create Windows registry entries for the new Content Server.
a. Open the registry and back it up.
b. Navigate to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\.
c. Locate the service key for the existing Content Server.
d. Use the Save Key menu to write out the key values for the existing Content Server service.
e. Create a new key with a new name.
f. Restore the key values you wrote out to the new key.
g. Change the ImagePath variable to include the path to the new server.ini file and a new log file.
For example, if the existing ImagePath is
d:\Documentum\product\6.5\bin\dmserver_v4.exe -repository_name
test1 -security acl -init_file
d:\Documentum\dba\config\test1\server.ini -run_as_service
-install_owner dmadmin -logfile
d:\Documentum\dba\log\test1.log
The new ImagePath would be:
d:\Documentum\product\6.5\bin\dmserver_v4.exe -repository_name
test1 -security acl -init_file
d:\Documentum\dba\config\test1\server1.ini -run_as_service
-install_owner dmadmin -logfile
d:\Documentum\dba\log\test1_1.log
The Windows documentation from Microsoft contains additional information on creating
a new service
8. Set the new Content Server to manual start mode using Start > Programs > Administrative
Tools > Services panel.
9. Restart the host.
10. Click Start > Programs > Administrative Tools > Services and start up the new Content Server.
11. Start IDQL and verify that the Content Server is running correctly:
$ IDQL caruso.caruso1 -Uusername -Ppassword
UNIX hosts
Use these instructions after a repository is configured to create additional servers for that repository
on the repository host. The Content Server Administration Guide provides instructions on configuring
additional servers for a repository on remote hosts.
To create this configuration, edit the etc/services file, which requires root privileges.
To configure additional servers on a UNIX host:

1. Connect to the repository as a superuser by using Documentum Administrator and create a new
server config object by saving the object with a new object name.
For example, if the existing server config object is called caruso, call the new server config
object caruso1.
In Documentum Administrator, navigate to Administration > Basic Configuration. From the File
menu, select Save As... and save the config object with a new name.
2. Disconnect from the repository.
3. Create a server.ini file for the new Content Server.
a. On the Content Server host file system, navigate to the $DOCUMENTUM/dba/config/
repository_name directory, where repository_name is the name of the repository.
b. Create a copy of the server.ini file called server1.ini.
c. Open the server1.ini file and add these lines:
service=caruso1
server_config_name=caruso1
These values must match the entries in the /etc/services file.
d. Save the server1.ini file.
4. Navigate to /etc/services and open the services file in a text editor.
5. Assign port numbers to the new Content Server.
For example, if these entries exist for the primary Content Server
dm_caruso 10000/tcp # repository service caruso
dm_caruso_s 10001/tcp # repository secure service
Add the following entries for the new Content Server:
dm_caruso1 10005/tcp # repository service caruso1
dm_caruso1_s 10006/tcp # repository secure service
6. Save the services file.

7. Navigate to the $DOCUMENTUM/dba directory and make a copy of the Content Server startup
and shutdown scripts:
cp dm_start_caruso dm_start_caruso1
cp dm_shutdown_caruso dm_shutdown_caruso1
8. Open the startup script in a text editor.

9. Change
logfile=$logdir/caruso.log
to
logfile=$logdir/caruso1.log
10. Change
./documentum -repository_name caruso -security acl -init_file
/trout1/documentum/dba/config/caruso/server.ini $@ >> $logfile 2>&1 &
to
./documentum -repository_name caruso -security acl -init_file
/trout1/documentum/dba/config/caruso1/server1.ini $@ >> $logfile 2>&1 &
11. Open the shutdown script in a text editor.

12. Change
DM_PID=`./iapi caruso -U$DM_DMADMIN_USER -P -e << EOF |
grep 'root_pid' | sed -e 's/ .*[: A-Za-z]//'
to
DM_PID=`./iapi caruso.caruso1 -U$DM_DMADMIN_USER -P -e << EOF |
grep 'root_pid' | sed -e 's/ .*[: A-Za-z]//'
13. Change
./iapi caruso -U$DM_DMADMIN_USER -P -e << EOF
to
./iapi caruso.caruso1 -U$DM_DMADMIN_USER -P -e << EOF
14. Save the shutdown file.

15. Start both servers:
dm_start_caruso
dm_start_caruso1
16. Start IDQL and verify that the Content Server is running correctly:
$ IDQL caruso.caruso1 -Username -Password
17. Check the log file for the new Content Server in $DOCUMENTUM/dba/log/caruso1.log.
Chapter 12
Creating a repository copy to test an
upgrade

• Creating the test environment, page 137
• Precopying tasks, page 138
• Copying a repository, page 139
Creating the test environment

You cannot create copies of more than one repository in a single new installation if the repositories
were created in different installations.
Use the instructions for creating a repository copy on the same platform as the original repository.
The procedure is not supported for moving a repository from one platform to another.
Before upgrading a repository, create an environment in which to test the upgrade process. To do
this, create a new installation using the original Content Server software version, copy the repository,
and upgrade that copy. After the upgraded copy is tested, upgrade the original repository.
For example, if you are copying two repositories, Paris and London, that were created in separate
Content Server installations, you need to copy them to separate Content Server installations. Creating
a repository copy requires you to copy the aek.key and dbpasswd.txt files from the original repository
host to the repository copy host, because each repository copy must have access to the aek.key and
dbpasswd.txt files from its original installation.
If you are copying two repositories, Tokyo and Beijing, that were created in the same Content
Server installation, you can create their copies in the same new installation, with the aek.key and
dbpasswd.txt files from the original installation copied to the installation where you create the copies.
If you want to test operations involving the content files, copy the content files to the repository
copy as well.
Creating a repository copy to test an upgrade
Precopying tasks
Before you create the repository copy, complete these tasks and note any appropriate values in
the Value column:
Table 12. Precopying tasks
Task Resource Value

Decide whether to copy the content
files.
Obtain the repository name. Consult the repository name: ____________
repository
administrator.
Obtain the repository ID from the Consult the repository ID: ____________
server.ini file. repository
administrator.
Obtain the repository owner’s name Consult the repository owner: ____________
and password. repository
administrator.
Create a database instance separate Consult the DBA.
from the database instance used by
the production repository.
Obtain connection information for Consult the DBA connection: ____________
the alternative database instance. and database
documentation
Identify a target host on which to target host: ____________
create the repository copy
Obtain the system or administrator Consult the DBA. admin user name: ____________
username and password for the
database.
Note the drive on which the drive: ____________
production repository resides.
Decide whether to create the copy
on the equivalent drive.
Decide whether to create the copy
on a drive equivalent to the drive
on which the production repository
resides. If the copy is on a different
drive, there are additional steps you
need to perform.
Copying a repository
In the instructions that follow, the test repository is called the repository copy. The original repository
is called the production repository.
Caution: The instructions that follow assume that the production repository is running on the
network while the repository copy is tested. However, shut down the production repository or
take it off the network while you test the repository copy. Conflicts and data corruption can
result from having two repositories on the network with the same name and repository ID.
To copy a repository:
1. Shut down the production repository.
2. On the target host, create a new Content Server installation and repository (the repository copy)
of the same version number as the production repository.
Follow the instructions in the Chapter 4, Installing Content Server, for the Content Server
installation.
Note: When you create the repository copy, ensure that you use the same repository name,
repository ID, and repository owner name and password as the production repository.
• When you create the repository copy, ensure that you use the same repository name,
repository ID, and repository owner name and password as the production repository.
• Ensure that you use a different database instance from the instance used by the production
repository and that you provide the correct connection information when you install.
For example, under Oracle the tnsnames.ora on the host where the repository copy resides
must point to the Oracle instance used by the copy, not the instance used by the production
repository.
• Ensure that the repository copy projects to a connection broker different from the connection
broker used by the production repository.
• Copy the $DOCUMENTUM/dba/secure/aek.key dbpasswd.txt files from the original host to
the same location on the repository copy host.
3. Apply to the repository copy any patches you applied to the production repository.
4. Connect to the database instance serving the production repository.
5. Use the database vendor’s tools to export all objects owned by the repository owner and export
the schema for the tables comprising the repository.
Contact the database vendor for any technical support you need to use the database tools.
6. On the production repository host’s file system, create a backup of the $DOCUMENTUM/data/
repository_name directory. This is the directory containing the repository’s content files.
7. Stop the repository copy.
8. Connect as the database system administrator to the database instance that is serving the
repository copy. For example, on Oracle, connect as the System account.
9. Destroy the existing tablespaces or database by using the dm_DeleteTableSpace.sql script in
$DOCUMENTUM/dba/config/repository_name/.
The scripts are database-specific. Run the script using the tools provided by the database vendor.
10. Delete the physical database file from the file system.
The name and location of the physical file are in the dm_CreateTableSpace.sql script.
11. Create new tablespaces or databases for the repository copy by using the dm_CreateTableSpace.sql
script in $DOCUMENTUM/dba/config/repository_name/.
The scripts are database-specific. Run the script by using the tools provided by the database
vendor.
12. Import the database export taken from the production repository into the newly created
tablespaces or database.
13. Verify that the database tables have the correct value for the test system hostname by checking
the following values:
• r_host_name in dm_server_config_s
• host_name in dm_mount_point_s
• target_server in dm_job_s
• projection_targets in dm_server_config_r
14. Connect to the database that is serving the repository copy as the repository owner .
15. If any of the values in Step 13 are incorrect, use SQL Server to correct the values.
16. Set the server to rebuild the Documentum views with this SQL Server statement:
update dm_type_s set views_valid=0
17. If you are testing operations that require the content files, copy the content file backup from the
production repository to the file system of the repository copy.
18. Navigate to the DOCUMENTUM/dba/config/repository_name directory and open the server.ini
file in a text editor.
19. Ensure that the preserve_existing_types key in the SERVER_STARTUP section is set to TRUE:
preserve_existing_types=T
20. Save the server.ini file.

21. Start the Content Server for the repository copy.
22. If you are testing the migration of a Web content management repository, modify the user objects
to reflect the new authentication domain.
a. Start IDQL and connect to the repository as the installation owner.
b. Run the following commands:
update dm_user objects
set user_os_domain =’new_machine_name’
where user_os_domain =’old_machine_name’
c. Disconnect from the repository and exit IDQL.

23. If the Content Server and content files of the copy reside on a drive different from the drive
used by the production repository, use IDQL to update the file_system_path attribute of the
dm_location and dm_mount_point objects to the new location:
update dm_location objects
set file_system_path='newpath' where file_system_path='old path'
update dm_mount_point objects

set file_system_path='newpath' where file_system_path='old path'
24. Deactivate all jobs by changing the is_inactive attribute on all job objects to TRUE.
25. Upgrade the repository copy to and verify the upgrade.
Appendix A
Required Environment Variables for
UNIX and Linux
This appendix lists the required environment variables for UNIX, Linux, and the databases.
If you are installing Content Server on UNIX or Linux, you need to set certain environment variables
in the installation owner’s environment. If you use the dm_launch_server_config_program.sh
script to start the Content Server configuration program, all required environment variables,
except for those required by each database are set automatically. If you do not use the
dm_launch_server_config_program.sh script, you need to manually set all environment variables.
You can set all of the following variables, except LC_ALL and DISPLAY, by sourcing
$DM_HOME/bin/dm_set_server_env.sh or $DM_HOME/bin/dm_set_server_env.csh. Set the
variables LC_ALL and DISPLAY in the installation owner’s .cshrc file (C shell) or .profile file (Bourne
or Korn shells). Alternatively, set the variables in a file called by the .cshrc file or .profile file or
in other ways permitted by UNIX.
Table 13. Required environment variables
Environment variable Description Required values

DOCUMENTUM Directory in which Content Any directory in the installation
Server is installed owner’s environment
DM_HOME Directory that contains the link $DOCUMENTUM/product/
to the directory containing the version_number
executables
DOCUMENTUM_SHARED Directory in which DFC is Any directory in the installation
installed owner’s environment
DISPLAY Controls the display localhost:0.0
LC_ALL C
Caution: If this value is

not set correctly, the Java
method server will fail.
Required Environment Variables for UNIX and Linux

PATH The path must include:
• JAVA_HOME/bin before the
following two variables
• $DM_HOME/bin
• $DOCUMENTUM/dba
JAVA_HOME Home directory for Java Ensure that $JAVA_HOME
installation on Content Server points to the Java version
host shipped by EMC Documentum,
$DOCUMENTUM_SHARED/
java/version_number, where
version_number is the Java
version for your platform
and Content Server version.
The Content Server Release
Notescontains the correct
version number.
CLASSPATH • $DOCUMENTUM_
SHARED/dctm.jar, which
must be first in the
CLASSPATH
• $DM_HOME/dctm-server.
jar
• $DOCUMENTUM_
SHARED/config
• $ORACLE_HOME/lib
LD_LIBRARY_PATH Solaris and Linux shared • The DFC location, $DM_
library path HOME/$DOCUMENTUM
_SHARED/dfc
• $JAVA_HOME/lib
• $DM_HOME/bin
• To use electronic signatures

on PDF documents,
$DM_HOME/fusion
• The index server location

$DOCUMENTUM/fulltext/
fast
• $JAVA_HOME/jre/lib/i386
• $ORACLE_HOME/lib
• $SYBASE_OCS/lib
• Both Solaris and Sybase

include a shared library
called libintl.so. With
Sybase, if you include
/usr/lib in the library path,
ensure that it is after any
Documentum or Sybase
directories
For Sybase 15.0 databases, this

path variable needs to point the
OCS-15_0/lib directory.
SHLIB_PATH HP-UX shared library path • The DFC location,
$DOCUMENTUM_
SHARED/dfc
• $DM_HOME/bin
• $DOCUMENTUM/fulltext/
fast
IndexServer/lib

on PDF documents,
$DM_HOME/fusion
• $JAVA_HOME/lib
• $JAVA_HOME/jre/bin/
classic
• $JAVA_HOME/jre/lib/PA_
RISC2.0/native_threads
• $JAVA_HOME/jre/bin
• If you are upgrading from

5.2.x on HP-UX and this
variable has a reference to a
version of Java that is 1.3 or
later, remove that reference
before upgrading.
• $ORCLE_HOME/lib
LIBPATH AIX shared library path • The DFC location,
$DOCUMENTUM_
SHARED/dfc
• $DM_HOME/bin
• $JAVA_HOME/lib
• $JAVA_HOME/jre/bin:
• $JAVA_HOME/jre/bin/
classic
fast
IndexServer/lib
• On DB2, $DB2_BASE/lib

on PDF documents,
$DM_HOME/fusion
• Any directories in the

database hierarchy
containing libraries you
need access to
• $ORCLE_HOME/lib
Note: On AIX-DB2, if the value
of the $LIBPATH variable is
too long and you are using
WebLogic as an application
server, a coredump can occur
when you start the application
server from within the Content
Server configuration program.
source $DM_HOME/bin/dm_
set_server_env.csh echo
$LIBPATH | wc
If the output is over 445, a
coredump might occur when
you start an application server
instance within the Content

To work around this issue,
run the start script to start the
administration server and the
application server instance
after exiting the Content
Avoid using a deep path for
$DOCUMENTUM_SHARED.
Appendix B
Content Server Installation Directories
and Repository Configuration Scripts
This appendix describes the file structure, scripts, and configuration objects that are a part of a
Content Server installation. The following topics are discussed:
• Content Server installation file structure, page 149
• Scripts run during installation or upgrade, page 154
• Configuration objects, page 157
Content Server installation file structure

A Content Server installation consists of a number of files distributed among several directories.
Some of these files, such as the executable files, are supplied as part of the Content Server installation
package. Others, such as the Content Server startup file, are created during the installation process.
The installation procedure creates the following subdirectories in the $DOCUMENTUM directory:
• _uninst
• data
• dba
• fulltext
• product
• server_uninstall
• share
_uninst
This directory contains the Content Server uninstaller.
Content Server Installation Directories and Repository Configuration Scripts
data
The files and directories in this category are the content storage areas. These directories must exist
and location objects must be defined for them in the repository before you start Content Server. The
installation procedure creates a default storage area and associated location object and a default
fulltext index object and associated location object.
The data directory contains directories that store the data manipulated by users and Content Server.
The installation procedure creates a subdirectory for the repository in the data directory and in that
repository subdirectory, creates a content storage area.
The data includes the fulltext indexes and the content files associated with objects in the repositories.
The location of these directories is the most flexible component of the configuration.
Most sites will want to add more storage areas and index directories, particularly as the repository
grows larger. The Content Server Adminsitration Guide provides information and instructions about
adding additional storage areas and fulltext index storage directories.
dba
The dba directory contains the log and config directories and several files.
• The log directory is where the Content Server places any log files generated by user actions during
a session with the Content Server. The Content Server creates any necessary subdirectories for
these log files under the log directory.
• The config directory includes a subdirectory for each repository that contains the startup files for
Content Server.
fulltext
The fulltext directory contains the third-party fulltext indexing software.
product
The product subdirectory contains the Content Server executables.
server_uninstall
This directory contains a script that you can run manually to destroy a repository’s database tables
after you delete the repository.
share
The share directory holds all the files that can be shared by the Content Server and the clients. Clients
that connect to the share directory remotely can benefit in file sharing and event notification. The
client must be using NFS software to receive these benefits. The Content Server Administration Guide
contains details.
The share directory has four subdirectories:
• data
The data directory contains data that is read and written by the Content Server and the clients.
The data directory has several subdirectories. Ensure that these subdirectories can be mounted
by clients.
— events
The events subdirectory contains a file for any user who has queued inbox items that have not
been viewed. The files are empty. They serve as a flag to the Content Server that items that
have not been viewed are in that user’s inbox.
— common
The common subdirectory is where the Content Server puts copies of requested content files if
users are not using client local areas and if users do not specify an alternate location for the files.
— clients
The clients subdirectory contains the win and unix subdirectories, which respectively contain
the files and executables for Windows and UNIX clients.
— temp
The temp subdirectory is used by the Content Server as a temporary storage space. For
example, results generated by the execution of a procedure by using the Apply method’s
DO_METHOD function are stored here.
— sdk
The sdk subdirectory contains two subdirectories of files that are useful to software developers.
The two subdirectories are:
— Include
This subdirectory contains the dmapp.h file and the import libraries.
— example
This subdirectory contains code examples.
Additional directories
The directories that are created during installation are described in Table 14, page 152 .
Table 14. Subdirectories created during installation
Directory Description
bin Contains the Content Server software.
convert Contains the transformation engine executable
files.
dba/auth When you install Content Server, a default
base directory is created. Under default base
directory the installer creates a subdirectory
specific to the repository. The repository
configuration also creates an auth_plugin
location object that points to the base directory
and sets the auth_plugin_location attribute in
the server to the name of the location object. Any
plugin installed in this directory is loaded into
every server at startup for all repositories. To use
a plugin only with a particular repository, place
the plugin in the repository-specific dba/auth
directory.
For example, if you want to use the

Netegrity plugin with a repository called
engr_db, move the Netegrity module to
the DOCUMENTUM\dba\auth\engr_db
directory.
When Content Server starts, it loads the plugins

found in its repository-specific directory first
and then those found in the base directory.
dba/secure/ldapdb Contains the secure connection attributes. You
need to define the following setup values to use
a secure LDAP connection:
• SSL mode
• SSL port
• Certificate database location
The ssl_mode attribute in the ldap_config object

defines whether the LDAP server is using a
secure or nonsecure connection. You need to set
this when defining the LDAP setup values.
To configure a secure connection, chose Secure

as the SSL mode. When you do, the interface lets
you edit the SSL port field. SSL port, represented
in the ldap config object by the ssl_port attribute,
identifies the port the LDAP server uses for the
secure connection. This value is 636 by default.
Certificate database location, represented in

the ldap_config object by the certdb_location
attribute, identifies the location of the certificate
database. The attribute value is the name of
the location object pointing to the certificate
database. The value is ldapcertdb_loc. The
directory that ldapcertdb_loc points to is
DOCUMENTUM\dba\secure\ldapdb.
example* Contains code examples.
external_apps Contains a shared library.
fusion Contains files required for electronic signature
functionality, a Trusted Content Services feature.
include* Contains header files for any external
applications that will communicate with
Content Server.
install Contains the installation scripts.
java Contains the Java package bundled with Content
Server.
messages *.e files (error messages).
Oracle Contains the language files needed by Oracle.
During installation, the environment variable
ORA_NLS33 is set to that location. Do not
remove that directory or reset the that variable.
tcf References the task chaining framework, which
is related to lifecycles and is part of the BPS and
BPM group.
Uniscape Contains NLS files for server code page
conversions.
unix* Contains the libraries for a UNIX client.
unsupported Contains executable files that are provided for
your convenience but that are not supported by
Content Server.
webcache Includes webcache.ini. The documentation
for Documentum Interactive Delivery
Services/Interactive Delivery Services
Accelerated contains details.
thumbsrv Installation directory for Thumbnail Server.
The documentation for Documentum Media
Services contains details.
win* Contains the executable files for a Microsoft
Windows client. These include IAPI and IDQL
* Optional for MS Windows and the DDE server and
libraries.
jboss Contains application server installation files
used to create an instance for the Java method
server.
Scripts run during installation or upgrade

During repository configuration, the following scripts are run, whether you are installing a new
repository or upgrading an existing repository:
Table 15. Repository configuration scripts
Script name Location Purpose Other

headstart.ebs $DM_HOME/install/ Loads the initial
admin default objects for
the repository. Creates
mount point objects,
location objects, file
store objects, and
method objects.
dm_apply_formats.ebs $DM_HOME/bin Creates or updates
format objects, which
are required for
content file operations.
dm_cas_install.ebs $DM_HOME/install/ Creates a method,
admin location, template
type, folder structure,
and template object for
use of the electronic
signature.
csec_plugin.ebs $DM_HOME/install/
admin
dm_routerconv_ $DM_HOME/install/ Loads methods that Run only during an
install.ebs admin are used for converting upgrade.
routers to workflow
template.

templates.ebs $DM_HOME/install/ Creates default
admin templates that are used
by EMC Documentum
clients for creating
new documents in the
repository.
replicate_bootstrap. $DM_HOME/bin Creates objects and
ebs registered tables
that are required for
replication.
desktop_client.ebs $DM_HOME/install/ Creates folders
desktop_client required by
Documentum Desktop
and installs the default
SmartList .
disable_fulltext_jobs. $DM_HOME/install/ Run only during an
ebs admin upgrade.
dfc.ebs $DM_HOME/install/ Loads default
admin objects required by
the Documentum
Foundation Classes.
Dfc_bof2.ebs $DM_HOME/install/ Creates the types for
admin dm_module, dmc_jar,
and dmc_java_library
and configures a
repository to use DFC
version 5.3 SP1 and
later.
dfc_javadbexpr.ebs $DM_HOME/install/ Creates types, relation
admin types, acls, and
repository folders
for DFC evaluation of
validation expression
constraints in Java.
dm_bpmmodules_ $DM_HOME/install/
install.ebs admin
createMethodServer- $DM_HOME/install/
Object.ebs admin
csec_plugin_upgrade_ $DM_HOME/install/ Upgrades the Run only during an
53.ebs admin plugin for using upgrade.
content-addressable
storage areas.
toolset.ebs $DM_HOME/install/ Installs repository
admin administration tools.

dm_bpm_install.ebs $DM_HOME/install/
admin
dm_wfTimer_ $DM_HOME/install/ Converts workflow Run only during an
upgrade.ebs admin pre- and post-timers upgrade.
set up in repositories
prior to version 5.3 to
the version 6.5 timer
implementation.
dmbasic -f
dm_wfTimer_
upgrade.ebs
-e Install --
repository_
nameuserpassword
dm_setup_java_ $DM_HOME/install/
lifecycle.ebs admin
create_fulltext_objects. $DM_HOME/install/ Creates repository
ebs admin objects related to
fulltext indexing.
dm_ldap_install.ebs $DM_HOME/install/ Creates or upgrades
admin the ldap config object
type and upgrades any
existing ldap config
objects.
dm_storageservices_ $DM_HOME/install/
install.ebs admin
dm_emailTemplate_ $DM_HOME/install/
install.ebs admin
dm_xml_install.ebs $DM_HOME/install/ Installs object types
admin and formats for XML
files.
dm_gwm_install.ebs $DM_HOME/bin Executes scripts
that install
workflow-related
types, methods,
folders, and jobs.
upgrade_java_ $DM_HOME/install/ Upgrades existing Java
methods_51.ebs tools methods.
ci_schema_install.ebs $DM_HOME/install/ Installs the object types
tools used by Documentum
Content Intelligence
Services.

display_config_setup. $DM_HOME/install/ Configures the
ebs tools repository for the
Documentum Offline
Client.
offline_config_setup. $DM_HOME/install/ Migrates offline
ebs tools configuration settings
from the offline_config
object to the docbase
config object.
upgrade_ $DM_HOME/install/ Run only during an
contentreplication_ admin upgrade.
job.ebs
dm_acs_install.ebs $DM_HOME/install/
admin
dd_populate.ebs $DM_HOME/bin Populates the data
dictionary with
attribute and type
information from
datafiles.
Configuration objects
Each repository contains objects that together define your configuration. These objects include:
• Server config object
• Docbase config object
• Fulltext index objects
• Location objects
• Mount point objects
• Storage objects
• Format objects
• Method objects
As you make choices about how to configure the installation and repositories, modify these objects or
add new ones. The Content Server Administration Guide contains details on configuration.
Appendix C
Troubleshooting a Content Server
Installation
This appendix contains information for troubleshooting common Content Server installation
problems. This appendix contains the following sections:
• Identifying the problem and resolution, page 159
• Recovering from a failed repository configuration or upgrade, page 162
• Enabling tracing in repository configuration scripts, page 163
• Recovering from a stalled Content Server upgrade, page 163
Identifying the problem and resolution

When experiencing a problem, perform the following preliminary actions:
• Ensure that you are connected as the installation owner.
• On UNIX and Linux, ensure that the environment variables are set correctly in the installation
owner’s environment.
Appendix A, Required Environment Variables for UNIX and Linux provides details.
• Review the Content Server installation logs.
Reviewing the Content Server installation logs, page 74 provides details.
Table 16, page 159 can help you identify the problem you are experiencing, a possible cause, and
recommended resolution."
Table 16. Troubleshooting checklist
Symptom Cause Fix

Content Server installation or You are trying to install or Connect using the installation
upgrade fails upgrade the Content Server but owner account.
you are not connected as the
installation owner.
The environment variables are
not set correctly.
Troubleshooting a Content Server Installation
Symptom Cause Fix

While installing a repository, Three possible causes of this To fix these three causes:
you see an error message that error: 1. Make the installation
indicates that the user is not a 1. The installation owner owner group the
valid UNIX user: account does not have installation owner’s
Configuration of the the installation owner primary group.
docbase fails with the group designated as the
user’s primary group. 2. Set the shared library
message 'user must be
Group ownership of the path environment variable
a valid unix user'
Documentum binaries is correctly. Appendix A,
exec(): 0509-036
incorrect. Required Environment
Cannot load program
Variables for UNIX
/u01/app/documentum/
2. The shared library path and Linux provides
product/5.2/bin/
environment variable is not information on setting
dmisvaliduser because
set correctly. environment variables
of the following
errors: 0509-150 3. On DB2, the $DB2_BASE 3. Chapter 3, Preparing the
Dependent module environment variable is not Database for Content
libldap50.so could not set correctly. Server Installation and the
be loaded. 0509-022 documentation for DB2
Cannot load module contain more information
libldap50.so. 0509-026
System error: A file
or directory in the
path name does not
exist.
Content Server upgrade There might be a cyclic group. Recovering from a stalled
appears unresponsive. Content Server upgrade, page
163 contains details.
On Windows hosts, you see The correct video driver for the Review the hardware and
the following error during video card is not installed on software configuration of the
installation: the host. host.
Could not initialize
interface awt exception
ExceptionInitializationError
You see the following error The dm_ContentReplication Delete the following entry from
during an upgrade of an older method has some parameter the dm_ContentReplication
repository: arguments left over from method:
EDMS98.
Failed to retrieve serverconfigname
serverconfig [domain\]user,passwd
object with name
<serverconfigname>.
***Failed to encrypt
passwords for
docbase ec_epac,
status -1057226550
**Operation failed **
Symptom Cause Fix

[DM_CRYPTO_E_NO_LOCAL_
COMPONENT_STORE] error:
"No local component
store for server"
Please read error log
C:\WINNT\Temp\dm_chec_
bin.ServerConfigurator.
log for more
information.
You see the following errors Invalid Oracle views belonging Make the views valid before
during upgrade from 5.3 to 6.5 to types _sv, _sp, _rv, and _rp. upgrading Content Server.
on Oracle 10:
A view in Oracle becomes To determine which views
Tue Feb 22 21:48:08 invalid when the base tables it in the Oracle installation
2005 098000 references change (for example, are invalid, you can run
[DM_SESSION_I_ by adding/dropping a column, the following query from
INIT_BEGIN]info: or dropping a unique constraint SQLPLUS logging in as the
"Initialize index). repository owner:
dmContent." Tue Feb
22 21:48:08 2005 select object_name,
567000 [DM_SESSION_ object_type from
I_INIT_BEGIN]info: user_objects where
"Initialize status='INVALID';
dmiSubContent." Tue
To recompile the views:
Feb 22 21:48:08 2005
598000 [DM_TYPE_MGR_E_ ALTER VIEW view_name
CANT_FIND_TABLE]error: COMPILE;
"Failure to find table
dmi_subcontent_sv The Oracle-supplied package
as part of fetch of named DBMS_UTILITY
type dmi_subcontent: has a procedure named
error from database COMPILE_SCHEMA. This
system is ORA-24372: procedure will compile all
invalid object for stored code, views, and so on,
describe" Tue Feb for the schema provided. The
22 21:48:08 2005 best way to compile all database
598000 [DM_SESSION_ objects that are invalid is to
E_INIT_FAILURE1]error: use a script in the $ORACLE_
"Failure to complete HOME/rdbms/admin directory
dmiSubContent named utlrp.sql. This script
initialization." finds all objects in the data
You might also see this dictionary that are invalid and
message: compiles them. This script is
typically mentioned in patch
ORA-24372: invalid notes but you can use it any
object for describe time a schema change occurs.
Error during session construction on Solaris-DB2

On Solaris-DB2 platform, when running cstests/acsRead test suites on version 6.5, the test cases
might fail with the following message:
"Unable to create session - error during session construction"
To work around this, make the following changes in the configuration:
1. Change MAXAPPLS using the following db2 command: UPDATE DATABASE CONFIGURATION
FOR <database_name> USING MAXAPPLS 200 AUTOMATIC MAXLOCKS 80 AUTOMATIC
2. Increase the number of semaphores as follows:
set noexec_user_stack=1
set semsys:seminfo_semmni=4096
set semsys:seminfo_semmns=16384
set semsys:seminfo_semmsl=4096
set semsys:seminfo_semvmx=32767
set semsys:seminfo_semopn=4096
set semsys:seminfo_semume=4096
set shmsys:shminfo_shmmax=4294967295
set shmsys:shminfo_shmmin=1
set shmsys:shminfo_shmmni=2400
set shmsys:shminfo_shmseg=50
Recovering from a failed repository

configuration or upgrade
If repository configuration fails, whether you are upgrading an existing repository or creating a new
one, you can recover from the failure.
Typical reasons for a failure include problems with the database connection or errors in Content
Server creation. Before you proceed with the following instructions, read the Content Server
installation logs and correct any problems. Reviewing the Content Server installation logs, page 74
provides details about logs.
To recover from a failed installation or upgrade:

1. Correct any problems noted in the Content Server installation logs.
2. Restart the Content Server configuration program.
3. Select Custom installation.
4. Select the repository where the failure occurred.
5. Check Upgrade.
This takes you through the configuration steps again and reruns the scripts that create the
repository.
Enabling tracing in repository configuration

scripts
When the repository configuration scripts fail, it helps to see the command that was being run at the
time of the failure in addition to the information in the output file. You can obtain this information by
enabling tracing in the scripts.
To enable tracing in the repository configuration scripts:

1. Restart the Content Server configuration program configuration program.
2. Select Custom installation.
3. At the where you can modify the configuration scripts, open the problem script for editing.
4. Immediately after the connect call, add the following line to the script:
sta$ = dmAPIExec("trace,c,4," & "trace_file_name")
5. Save the script.

6. Rerun the script.
Recovering from a stalled Content Server

upgrade
A Content Server upgrade that stalls in the middle or takes hours to complete can be caused by
cyclic groups. A cyclic group is a subgroup of a member group, causing the Content Server to cycle
during the upgrade. If the Content Server has encountered a cyclic group, the last line of the Content
Server log is:
Thu Jun 28 14:00:14 2007 715540 [DM_SESSION_I_INIT_BEGIN]info:"Initialize dmGroup."
Use the following instructions to identify the cyclic group. After you locate the cyclic group, contact
EMC Documentum Technical Support for assistance in correcting the problem, which requires direct
SQL Server statements in the database.
To identify and correct a cyclic group:

1. From the operating system, stop the Content Server startup.
• On Windows, open Task Manager, select the correct Content Server process on the Processes
tab, and click End Process.
• On UNIX and Linux, determine the correct Content Server process and use the kill command
to end the process.
2. If you are on UNIX or Linux, restart the Content Server using the –osqltrace option:
dm_start_repositoryname -osqltrace
3. If you are on Windows, edit the Content Server startup command, then restart the Content Server.
a. Click Start > Programs > Documentum > Server Manager.
b. Select the correct repository.
c. Click Edit Service.

d. In the Command field, add -osqltrace after the repository name.
e. Click Okay.
f. Restart the Content Server.
4. When the Content Server appears to be unresponsive, open the Content Server log and identify
the query that is looping.
If there is a cyclic group, the last query in the log is recorded multiple times and takes this format:
Thu Jun 28 13:33:17 2007 435439: 21547[1]
SELECT SB_.R_OBJECT_ID FROM repository_owner.dm_group_s SB_
WHERE (SB_.R_OBJECT_ID=:objectp AND SB_.I_VSTAMP=:versionp)
Thu Jun 28 13:33:17 2007 435608: 21547[1] :objectp = 1200fb8080000909
Thu Jun 28 13:33:17 2007 435608: 21547[1] :versionp = 0
In the preceding example, the cyclic group has the r_object_id of 1200fb8080000909.
5. Run the following query:
SELECT group_name
FROM dm_group_s
WHERE r_object_id='r_object_id_of_cyclic_group
This query returns the name of the group, which you need for determining which group is
the cyclic group.
6. Run the following query:
SELECT groups_names
FROM dm_group_r
WHERE r_object_id = ‘r_object_id_of_cyclic_group’
The query returns the names of each group that is a member of the problem group.
7. For each of the group names returned, run this query:
SELECT r_object_id from dm_group_s where group_name = ‘member_group_name'
The query returns the r_object_id for each member group.
8. Repeat steps 6 and 7 iteratively for each subgroup until you locate the cyclic group.
9. Contact EMC Documentum Technical Support for assistance in correcting the problem.
Appendix D
Object Type Categories for Oracle
Database Storage
This appendix lists the object types by their size category. An object type’s size category is used
in two contexts:
• To determine where to create the object type’s tables and indexes if the optional
[FUNCTION_SPECIFIC_STORAGE] parameters are defined in the server.ini file
• To determine the default initial and next extent allotments for the object type’s tables in the RDBMS
This appendix contain the following topics:
• Type categories for tablespace specifications, page 165
• Type categories for extent allocation, page 166
The categories for each context are not the same. Type categories for tablespace specifications, page
165, helps you to find the categories for tablespace determination and to Type categories for extent
allocation, page 166, shows the tables listing the categories for extent allotments.
Appendix E, Defining Oracle or DB2 Database Parameters for Repository Tables provides information
about setting the default storage parameters.
Type categories for tablespace specifications

By default, the tables and indexes for all object types are created in the same tablespace. However,
you can set parameters in the server.ini file to define alternate tablespaces for large and small
object types. When you do so, the system sorts the objects into large and small for the purposes of
determining which object types to create in which tablespace.
The majority of the object types are considered small for this purpose. The following list shows the
object types that are considered large. Any type not appearing on this list is considered small.
dm_acl dm_process dmi_dump_object_record

dm_assembly dm_reference dmi_linkrecord
dm_audittrail dm_relation dmi_load_object_record
dm_composite dm_router dmi_otherfile
dm_document dm_script dmi_queue_item
Object Type Categories for Oracle Database Storage
dm_folder dm_smart_list dmi_replica_record

dm_locator dm_sysobject dmr_containment
dm_note dm_workflow dmr_content
dm_procedure dm_workitem
Type categories for extent allocation

This section lists object type size categorizations for extent allocation and the default initial and
next extent storage parameters for each category.
The object types are categorized as large, small, or default based on how many objects of the type
will be created in the repository. For example, dm_document is categorized as large because most
enterprises create large numbers of documents in a repository. Similarly, dm_docbase_config is
categorized as small because a repository has only one docbase config object. Those types that do not
fall into either the large or small category are categorized as default.
Object types categorized as large

The object types categorized as large are created with an initial extent size of 100 K. The next extent
size is 1 M. The following object types are categorized as large for the purposes of allocating extents.
dm_acl dm_reference dmi_dump_object_record

dm_assembly dm_relation dmi_load_object_record
dm_document dm_router dmi_object_type
dm_folder dm_sysobject dmi_queue_item
dm_locator dmi_containment dmi_replica_record
dm_note dmr_content dmi_subcontent
Object types categorized as small

The object types categorized as small are created with an initial extent size of 10 K. The next extent
size is 50 K. The following object types are categorized as small for the purposes of allocating extents.
dm_alias dm_filestore dm_relation_type

dm_blobstore dm_foreign_key dm_server_config
dm_distributed_store dm_format dm_store
dm_dump_record dm_fulltext_index dmi_change_record
dm_docbase_config dm_linkedstore dmi_expr_code
dm_docbaseid_map dm_load_record dmi_recovery

dm_extern_file dm_location dmi_session
dm_extern_free dm_mount_point dmi_sequence
dm_extern_store dm_opticalstore dmi_tdk_collect
dm_extern_url dm_outputdevice dmi_tdk_index
dm_federation dm_registered dmi_vstamp
Object types categorized as default

The object types categorized as default are created with an initial extent size of 20K. The next extent
size is 100K. The following object types are categorized as default for the purposes of allocating
extents.
dm_acs_config dm_cabinet dm_domain

dm_activity dm_client_registration dm_expression
dm_aggr_domain dm_client-rights dm_federation_log
dm_application dm_cond_expr dm_func_expr
dm_app_ref dm_cond_id_expr dm_group
dm_aspect_type dm_component dm_job
dm_audittrail dm_cont_transfer_config dm_job_request
dm_bocs_config dm_dd_attr_info dm_key
dm_builtin_expr dm_dd_info dm_ldap_config
dm_cabinet dm_dms_config dm_lightweight
dm_literal_expr dm_public_key_certificate dm_user
dm_media_profile dm_query dm_value_assist
dm_method dm_qual_comp dm_value_func
dm_nls_dd_info dm-retainer dm_value_list
dm_plugin dm_script dm_value_query
dm_policy dm_smart_list dm_validation_descriptor
dm_process dm_staged dm_workflow
dm_procedure dm_type dm_workitem
dmc_aspect_type dmc_relationship_def dmc_wfsd_element_string
dmc_calendar dmc_routcase_condition dmc_wfsd_parent
dmc_calendar_event dmc_scope_config_relation dmc_wfsdrp_boolean
dmc_completed_workitem dmc_transition_condition dmc_wfsdrp_date
dmc_datatable dmc_type_info dmc_wfsdrp_double
dmc_datatable_row dmc_wf_package_skill dmc_wfsdrp_integer
dmc_datatable_schema dmc_wfsd_element dmc_wfsdrp_parent

dmc_datatable_settings dmc_wfsd_element_boolean dmc_wfsdrp_string
dmc_module dmc_wfsd_element_date dmc_workqueue
dmc_preset_info dmc_wfsd_element_double dmc_workqueue_policy
dmc_preset_package dmc_wfsd_element_integer dmi_autittrail_attrs
dmi_dist_comp _record dmi_package dmi_registry
dm_expr_code dmi_transactionlog dmi_wf_timer
dmi_workitem
Appendix E
Defining Oracle or DB2 Database
Parameters for Repository Tables
To improve performance and increase the throughput of the system, you might want to control where
repository information is stored. For example, you can store frequently used data on different disks
than less frequently used data. Defining database parameters to store data in different tablespaces
also partitions data into smaller, more manageable pieces.
When a repository is created, the system automatically creates object-type tables and indexes in the
underlying database. The object-type tables and indexes are described in Content Server Fundamentals.
If you do an express installation of Content Server, by default, Content Server creates all object-type
tables and indexes in the same tablespace. The size and number of the extents allotted for each
table are determined by default configuration parameters. If you do a custom Content Server
installation, you are prompted to configure the object-type tables and indexes, and you can create
them in separate tablespaces.
You can edit the server.ini file to change any configuration parameters when the repository is created,
before you start the Content Server.
• On DB2, you can change the tablespace for the object-type tables and indexes. On Oracle, you
can change two parameters:
— The tablespace for the object-type tables and indexes
— The size of the extents allotted for system-defined object types
You cannot change the number of extents allotted for the object types.
• Under Oracle 10, always create tablespaces as locally managed tablespaces (LMTs) using the
LOCAL value. If you have dictionary managed tablespaces (DMTs) under Oracle 10, use the
Oracle DBMS_SPACE_ADMIN package to convert DMTs to LMTs, for example,
SQL> exec dbms_space_admin.Tablespace_Migrate_TO_Local('Table_space1');
The Oracle documentation set contains details on extent management and DMT-to-LMT
conversion.
Defining the tablespace

The parameters in the [FUNCTION_SPECIFIC_STORAGE] and [TYPE_SPECIFIC_STORAGE]
sections of the server.ini file define the tablespace in which to create the object-type tables and indexes.
Defining Oracle or DB2 Database Parameters for Repository Tables
FUNCTION_SPECIFIC_STORAGE
Set the parameters in the [FUNCTION_SPECIFIC_STORAGE] section to define the tablespace for the
type tables and indexes for a particular category of object types. EMC Documentum sorts object types
into the categories large and small for the purposes of defining their tablespace.
• Object types in the large category are those that are expected to have a large number of object
instances. For example, dm_SysObject is in the large category.
• Object types in the small category are those that are expected to have very few object instances.
For example, dm_docbase_config is in the small category. Each repository has only one Docbase
config object.
The format of the [FUNCTION_SPECIFIC_STORAGE] section is:
[FUNCTION_SPECIFIC_STORAGE]
database_table_large=tablespace_name
database_table_small=tablespace_name
database_index_large=tablespace_name
database_index_small=tablespace_name
For example, to define a tablespace for the object-type tables in the large category, include the
following lines in the server.ini file, substituting the name of the tablespace:
database_table_large=tablespace_name
For example, to put the indexes for the large category in the tablespace named production_1, include
the following lines in the server.ini file:
database_index_large=production_1
You can specify the function-specific parameters singularly or in any combination.
TYPE_SPECIFIC_STORAGE
Set the parameters in the [TYPE_SPECIFIC_STORAGE] section in the server.ini file to define a
tablespace for the type tables or indexes for a specific object type.
The format of the [TYPE_SPECIFIC_STORAGE] section is:
[TYPE_SPECIFIC_STORAGE]
database_table_typename=tablespace_name
database_index_typename=tablespace_name
You can specify the type-specific parameters individually. For example, to put the object-type
tables for the dm_SysObject type the tablespace named sysobj_space, include the following lines
in the server.ini file:
database_table_dm_sysobject=sysobj_space
If you want to put both the tables and indexes for an object type nondefault tablespaces, define the
tablespace for each. Defining a tablespace for an object type’s tables does not affect where the type’s
indexes are stored. The system creates the indexes in the default tablespace. Defining a tablespace for
a type’s indexes does not affect where the type’s tables are stored.
For example:
database_index_dm_sysobject=sysobj_idx_space
The object-type tables and indexes of any object type not specified in a type-specific parameter are
created in the default tablespace or, if specified, in the tablespace for the type’s category.
If the server.ini file includes both function-specific and type-specific parameters that apply to an
object type, the type-specific parameters override the function-specific parameters. For example,
suppose you add the following function-specific and type-specific parameters to the file:
database_index_large=production_1
Both parameters apply to the dm_SysObject type because dm_SysObject is in the large category.
The object-type tables for dm_SysObject are created in the sysobj_space tablespace because the
type-specific parameter overrides the function-specific parameter.
Defining the Oracle extent sizes

For the purposes of extent allocation, the Documentum object types are sorted into three categories:
large, small, and default. The category name describes the quantity of expected objects of the type.
For example, dm_document is considered a large type because most enterprises generate large
quantities of documents. In contrast, dm_repository_config is a small type because there is only one
docbase config object in a repository. Those object types that typically do not have large numbers of
objects or very small numbers of objects fall into the default category.
A type’s category determines how much database storage is allocated to it by default. Object types
categorized as:
• Large object type receive an initial extent of 100 KB and a next (second, third, fourth.) extent of
1 MB.
• Small object types receive an initial extent of 10 KB and a next extent of 50 KB.
• Default object types receive an initial extent of 20 KB and a next extent of 100 KB.
The default storage parameters set the initial and next extent sizes. There are also parameters that
define the default minimum and maximum number of extents allotted to an object type table and
the percentage increase of extents allotted after the second extent. The minimum number of allotted
extents is 1 and the maximum number is determined by Oracle, based on the data block size. By
default, object-type tables and indexes are allocated the minimum number of extents when they
are created.
The percentage increase default is 10 percent. This means that extents allotted after the second extent
are increased in size by 10 percent over the previously allocated extent. For example, if the second
extent’s size is 100 KB, then the size of the third extent is 110 KB, 10 percent greater than 100 KB. The
fourth extent would be 121 KB, 10% greater than 110 KB.
You can change the initial and next extent default sizes for an individual object type or for an entire
category by setting parameters in the server.ini file before the repository is created.
You can change the following parameters by using the Oracle ALTER TABLE command through
sqlplus:
• Next extent
• Minimum extent
• Maximum extent
• Percentage increase
The Oracle documentation contains instructions.
Changing storage parameters for individual object

types on Oracle
To change the initial and next extent parameters for an object type, add a [TYPE_EXTENT_SIZE]
section to the server.ini file. This section has the following format:
[TYPE_EXTENT_SIZE]
database_ini_ext_typename=new_value[K|M]
database_next_ext_typename=new_value[K|M]
• typename must be the internal name of a system-defined object type. It cannot be a user-defined
object type.
• The database_ini_ext_typename parameter defines the size of the initial extent allotted to the type.
• The database_next_ext_typename parameter defines the size of the second extent allotted to the type.
• new_value is an integer. If you include K, the value is interpreted as Kilobytes. If you include M, the
value is interpreted as Megabytes. If you include neither K nor M, the value is interpreted as bytes.
For example, to change the defaults for dm_sysobject, add the following lines to the server.ini file:
[TYPE_EXTENT_SIZE]
database_ini_ext_dm_sysobject=new_value[K|M]
database_next_ext_dm_sysobject=new_value[K|M]
You can set either parameter or both for an object type. The section can include parameter
definitions for more than one object type. For example:
[TYPE_EXTENT_SIZE]
database_ini_ext_dm_sysobject=new_value[K|M]
database_next_ext_dm_sysobject=new_value[K|M]
database_next_ext_dm_user=new_value[K|M]
Changing storage parameters for categories of types

on Oracle
To change the initial and next extent parameters for all object types in one category, add a
[FUNCTION_EXTENT_SIZE] section to the server.ini file. This section has the following format:
[FUNCTION_EXTENT_SIZE]
database_ini_ext_large=new_value[K|M]
database_ini_ext_small=new_value[K|M]
database_ini_ext_default=new_value[K|M]
database_next_ext_large=new_value[K|M]
database_next_ext_small=new_value[K|M]
database_next_ext_default=new_value[K|M]
• The database_ini_ext_large parameter defines the size of the initial extent allotted by default
to object types categorized as large.
• The database_ini_ext_small parameter defines the size of the initial extent allotted by default to
object types categorized as small.
• The database_ini_ext_default parameter defines the size of the initial extent allotted by default to
object types categorized as default.
• The database_next_ext_large parameter defines the size of the second extent allotted by default
to object types categorized as large.
• The database_next_ext_small parameter defines the size of the second extent allotted by default to
object types categorized as small.
• The database_next_ext_default parameter defines the size of the second extent allotted by default to
object types categorized as default.
• new_value is an integer. If you include K, the value is interpreted as Kilobytes. If you include M, the
value is interpreted as Megabytes. If you include neither K nor M, the value is interpreted as bytes.
For example, to change the default extent sizes for all large object types, add the following
to the server.ini file:
database_ini_ext_large=new_value[K|M]
database_next_ext_large=new_value[K|M]
You can set any combination of the parameters. It is not necessary to set the parameters for all
three categories. You can also set only one of the parameters for a category. To illustrate, the
following example sets the initial extent for objects categorized as large and the next extent for
object types categorized as default:
database_ini_ext_large=200K
database_next_ext_default=120K
User-defined object types

A user-defined object type derives its database storage parameters from its supertype. If the type
has no supertype, then the type is assigned to the large category for tablespace assignment and to
the default category for the extent allocations
You cannot change the storage parameters for user-defined object types.
On DB2, if you create a tablespace for objects of type dm_SysObject, then create a user-defined object
type whose supertype is dm_SysObject, the user-defined object type is not stored in the tablespace
for dm_SysObject. Instead, the user-defined object type is stored in the default tablespace, unless
you define the tablespace for dm_SysObject in the server.ini file.
Index
A code pages
accounts supported, 32
installation owner, 33 common directory, 151
repository owner, 22, 34, 45 config directory, 150
acs.properties file configuration
administration, 100 basic server installation, 154
active/active clusters, 128 default, 154
connection broker generic application file locations, 151
resources, 129 objects, described, 157
Content Server service resources, 129 overview, 157
described, 117, 127 requirements, 36
first cluster resource group, 127 to 128 configuration decisions
repository configuration, 128 repository size, 22
server.ini file, 128 configuring
verifying failover, 130 repositories, 63, 68
active/passive clusters configuring Content Server, 21
configuring, 118 CONNECT privileges, 46
configuring the repository, 119 connecting to database, 21
connection broker configuration, 124 connection broker
creating resource groups, 118 required ports, 25
creating resources, 125 connection brokers
described, 116 described, 15
installing Content Server, 119 generic application resources, 129
verifying failover, 126 in resource groups, 115
administrative tool scripts, 68 Microsoft Cluster Services, 124
aek.key file, 137 Content Server
configuration, 21
connection types, 24
B Content Storage Services, 27
backing up key store files, 79 in resource groups, 115
installation owner, 33
internationalization, 32
C Retention Policy Services, 27
ci_schema_install.ebs script, 156 service resource, 129
client connections, 24 Trusted Content Services, 26
clients directory, 151 uninstalling, 97
cluster resource groups uninstalling Content Server, 95 to 97
creating, 118 Content Services for retention type store
resources, 118 described, 26
cluster resources Content Storage Services, 27
creating, 125 content-addressed storage, 26
Index
copying repositories, 137 SDK, 151

create_fulltext_objects.ebs, 156 share, 151
CSEC. See Content Services for retention temp, 151
type store version, 36
csec_plugin_upgrade_53.ebs, 155 disks, shared, 117
cyclic groups, 163 display_config_setup.ebs script, 157
distributed configurations
installation requirements, 108
D shared content model, 108
data directories, described, 22, 150 upgrading, 109
database UTC time, 108
code page, 44 distributed content, 110
database accounts, 21 dm_apply_formats.ebs script, 154
database location, 117 dm_cas_install.ebs, 154
database requirements dm_change_password, 36
repository owner, 34, 45 dm_check_password, 36
database_refresh_interval key, 86 dm_gwm_install.ebs script, 156
databases DM_HOME environment variable, 36, 150
DB2, 50 dm_ldap_install.ebs script, 156
installation location, 21 dm_root_task script, 36
Oracle requirements, 47 dm_routerConv_install.ebs script, 154
requirements, 44 dm_wfTimer_upgrade.ebs, 156
requirements for upgrade, 86 dm_xml_install.ebs script, 156
SQL Server requirements, 48 docu, 23
Sybase, 49 Documentum Administrator
UTF-8, 86 adding groups, 80
Windows requirements, 45 Documentum Content Intelligence
DB2 Services, 156
current configuration, 51 DOCUMENTUM environment variable, 36
environment variables, 51 Documentum Foundation Classes
performance wizard, 50 dfc.ebs script, 155
repository owner requirements, 46 Documentum Offline Client, 157
requirements, 50
dba directory, 150
dd_populate.ebs script, 157 E
desktop_client.ebs script, 155 EMC Documentum Site Caching
dfc.ebs script, 155 Services, 108
directories EMC Documentum Web Publisher, 108
clients, 151 enabling repository configuration script
common area, 151 tracing, 163
config, 150 environment variables, 36
content storage, 117 DB2, 51
data, 22, 150 DM_HOME, 36
dba, 150 DOCUMENTUM, 36
DM_HOME, 150 installation owner environment, 143
event subdirectory, 151 LANG, 32
events, 151 library path, 145
log, 150 ORACLE_HOME, 47
product, 149 Sybase, 50
required for installation, 36 events subdirectory, 151
Index
exiting installation, 60 required permissions On UNIX and

external password checking, 34 Linux, 34
external password validation, 34 root account, 33
SQL Server, 34
Sybase requirements, 50
F uninstalling Content Server, 95 to 97
failover, 116 username, 33
failover verification, 130 Windows domain requirements, 34
failover, verifying, 126 Windows requirements, 33
files Windows rights, 34
aek.key, 137 installation owner group, 34
initlora, 47 installing
services, 36 to 37 copying server software, 55
spfile, 47 sequence, 55
Sybase configuration, 49 installing content server
tnsnames.ora, 47 required ports, 25
installing Content Server
G basic configuration for server, 154
configuration requirements, 36
generic application resources, 129
configuration scripts, 154
global registry
configuring repositories, 119, 128
network locations, 25
connection brokers, 15
SBOs, 25
copying software, 57, 60
groups, 80
database, 50
installation owner, 34
DB2, 50
directory structure, 149
H environment variables, 143
hardware requirements, 29 exiting, 60
headstart.ebs script, 154 hardware requirements, 29
host locales, 32 Microsoft Cluster Services, 115
host preparation multiple servers on UNIX and
UNIX, 35 Linux, 133
hostname requirement, 31 multiple servers on Windows, 133
hosts, 31 preparing, 29
repository size, 22
typical configurations, 15
I UNIX group accounts required, 33
index agent internationalization, 32
required ports, 25 database code page, 44
index server server host code pages, 32
required ports, 25 SQL Server, 44
init.ora file, 47 Unicode, 44
installation owner, 34 UTF-8, 86
case-sensitivity of username, 33
changing, 77
described, 33 J
domains, 34 Java method server
environment variables, 143 required ports, 25
password, 33 JMX password, changing, 100
Index
K CONNECT privileges, 45
key store files, backing up, 79 database aliases, 47
environment variables, 47
MAX_COMMIT_PROPAGATION_
L DELAY parameter, 47
LANG environment variable, 32 optimizing, 47
load—balanced configurations, 108 ORACLE_HOME, 47
local administrators group, 34 preinstallation requirements, 47
local database installations, 21 Real Application Clusters, 47
log directory, 150 repository owner requirements, 46
logs, server installation, 74 repository sizes, 48
RESOURCE privileges, 45
TNS aliases, 47
M tnsnames.ora file, 47
Microsoft Cluster Services, 128 ORACLE_HOME environment
active/active clusters, 117 variable, 47
active/passive clusters, 116 to 117 order of uninstalling, 95
configuration options, 116
configuring active/active clusters, 127
configuring active/passive clusters, 118 P
to 119 passwords, 33, 35
configuring connection brokers, 124 port numbers, 37
configuring the repository, 128 ports
connection broker projection, 128 native connections, 36
Content Server service resource, 129 required, 25
content storage directories, 117 secure connections, 36
database location, 117 postinstallation tasks
Documentum configurations, 116 adding groups, 80
installation choices, 116 adding users, 80
modifying server.ini file, 128 administrative tool script, 68
preinstallation tasks, 117 PURGE AUDIT, enabling, 80
repository owner, 34 reviewing server installation logs, 74
resource groups, 115 preinstallation requirements
shared disks, 117 database, 21
user permissions, 118 database administrator account, 46
verifying failover, 130 database code page, 44
DB2, 50
directories, 36
N DM_HOME, 36
native connections, 24, 37 environment variables, 143
network cards, 31 hostname, 31
network location objects, 25 hosts, 31
installation directory, 36
O repository owner, 22, 45
supported code pages, 32
object replication, 110
XWindows, 35
object type categories, 165
product directory, described, 149
ODBC configuration, 48
PURGE AUDIT job, 80
offline_config_setup.ebs script, 157
Oracle
Index
R Oracle, 46
remote database installations, 21 password, 35
remote domains, 34 RDBMS account, 22, 45
replicate_bootstrap.ebs script, 155 required Windows privileges, 46
repositories SQL Server, 46
active/active clusters, 128 username, 34
active/passive cluster, 118 Windows, 34
configuring, 63, 68, 119, 128 requirements
copying, 137 ports, 25
global registry, 25 reserved terms, 23
owner, 46 resource groups, 115
services file entries, 37 RESOURCE privileges, 46
size, 22 Retention Policy Services, 27
user authentication, 35 root account, 33
users, 35 root password, 85
repository root task, 36
ID, 23
name, 23 S
repository configuration failure, 162 scripts
repository configuration scripts dm_root_task, 36
ci_schema_install.ebs, 156 repository configuration, 154
create_fulltext_objects.ebs, 156 server configuration, 123
csec_plugin_upgrade_53.ebs, 155 SDK directory, 151
dd_populate_install.ebs, 157 secure connections, 24, 37
desktop_client.ebs, 155 semaphore requirements, 35
dfc.ebs, 155 server installation logs, 74
display_config_setup.ebs, 157 server.ini file, 128
dm_apply_formats.ebs, 154 database_conn key, 47
dm_cas_install.ebs, 154 services file, 36
dm_gwm_install.ebs, 156 port numbers, 37
dm_ldap_install.ebs, 156 service name, 37
dm_routerConv_install.ebs, 154 share directory, described, 151
dm_wfTimer_upgrade.ebs, 156 shared content configurations, 108
dm_xml_install.ebs, 156 shared disks, 117
headstart.ebs, 154 shared memory requirements, 35
offline_config_setup.ebs, 157 size of repository, 22
replicate_bootstrap.ebs, 155 spfile, 47
templates.ebs, 155 SQL Server
toolset.ebs, 155 custom installation, 48
upgrade_java_methods_51.ebs, 156 enabling case-sensitivity, 48
repository copies, 137 enabling row-level locking, 48
repository federations internationalization, 44
upgrading, 109 ODBC configuration, 48
repository owner repository owner requirements, 46
database privileges, 45 requirements, 48
database requirements, 46 stalled server upgrade,
DB2, 46 troubleshooting, 163
described, 22, 45 Sybase
Microsoft Cluster Services, 34 configuration file, 49
Index
devices, 50 space available, 36

environment variables, 50 XWindows, 35
installation owner, 50 unsecure connections, 24
requirements, 49 upgrade_java_methods_51.ebs script, 156
upgrading Content Server
database_refresh_interval ey, 86
T described, 83
temp directory, described, 151 distributed configurations, 109
templates.ebs script, 155 distributed content, 110
Terminal Services, 110 effects on system, 83
testing an upgrade, 137 object replication, 110
tnsnames.ora file, 47 repository federations, 109
toolset.ebs script, 155 testing, 137
troubleshooting UTF-8, 86
diagnosis, 159 users, 80
enabling repository configuration authentication on Windows, 35
script tracing, 163 UTC time, 108
repository configuration failure, 162 UTF-8 code page, 32
stalled server upgrade, 163
Trusted Content Services
described, 26 V
port numbers, 37 verifying failover, 126, 130
services file, 37 version directory, 36
virtual IP addresses, 115
virtual network hostnames, 115
U
Unicode, 44
uninstalling Content Server, 97 W
Content Server, 95 Windows
installation owner, 95 to 97 installing multiple servers, 133
order, 95 repository owner, 46
requirements, 95 to 97 user authentication, 35
UNIX Windows requirements
host preparation, 35 database service, 45
installing multiple servers, 133 installation owner account, 33
UNIX requirements, 36 installation owner user rights, 33
directories, 36 local administrators group, 34
environment variables, 36, 143 repository owner, 34
installation owner account, 34 Terminal Services, 110
root account, 33
semaphores, 35
services file, 36
X
shared memory, 35 XWindows, 35
shells, 143

Content Server Install Guide 6.5 SP2

Загружено:

Сведения о документе

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Content Server Install Guide 6.5 SP2

Загружено:

Авторское право:

Доступные форматы

EMC ® Documentum ®

Chapter 2 Preparing the Host for Content Server Installation ...................................... 29

EMC Documentum Content Server Version 6.5, SP2 Installation Guide 3

Preparing Windows hosts ................................................................................. 37

Chapter 3 Preparing the Database for Content Server Installation .............................. 41

Chapter 4 Installing Content Server ............................................................................. 55

Chapter 5 Completing the Installation ......................................................................... 75

4 EMC Documentum Content Server Version 6.5, SP2 Installation Guide

Chapter 6 Upgrading Content Server ........................................................................... 83

Chapter 7 Uninstalling Content Server ........................................................................ 95

Chapter 8 Installing Documentum Messaging Services ............................................... 99

Chapter 9 Installing Remote Content-File Servers in Distributed or

EMC Documentum Content Server Version 6.5, SP2 Installation Guide 5

Creating additional cluster resources ........................................................... 125

Chapter 11 Configuring Multiple Content Servers on a Single Host for a

Chapter 12 Creating a repository copy to test an upgrade .......................................... 137

Appendix C Troubleshooting a Content Server Installation .......................................... 159

6 EMC Documentum Content Server Version 6.5, SP2 Installation Guide

Appendix E Defining Oracle or DB2 Database Parameters for Repository

EMC Documentum Content Server Version 6.5, SP2 Installation Guide 7

Figure 1. Repository structure ............................................................................................. 14

8 EMC Documentum Content Server Version 6.5, SP2 Installation Guide

Table 1. Host preparation checklist..................................................................................... 29

EMC Documentum Content Server Version 6.5, SP2 Installation Guide 9

10 EMC Documentum Content Server Version 6.5, SP2 Installation Guide

Purpose of the manual

EMC Documentum Content Server Version 6.5, SP2 Installation Guide 11

12 EMC Documentum Content Server Version 6.5, SP2 Installation Guide

Content Server and repository overview

EMC Documentum Content Server Version 6.5, SP2 Installation Guide 13

Figure 1. Repository structure

Content Server installation models

14 EMC Documentum Content Server Version 6.5, SP2 Installation Guide

Basic installation model

Figure 2. Basic installation model and component installation order

EMC Documentum Content Server Version 6.5, SP2 Installation Guide 15

Single-repository model with content stored at primary

16 EMC Documentum Content Server Version 6.5, SP2 Installation Guide

EMC Documentum Content Server Version 6.5, SP2 Installation Guide 17

Figure 4. Remote sites using primary site’s ACS server

The Distributed Configuration Guide provides details about this model.

Single-repository distributed model with content in a

18 EMC Documentum Content Server Version 6.5, SP2 Installation Guide

The Distributed Configuration Guide provides details about this model.

Multirepository distributed model by using object

EMC Documentum Content Server Version 6.5, SP2 Installation Guide 19

Figure 6. Object replication model

The Distributed Configuration Guide provides details about this model.

Multirepository distributed model working as a

Figure 7. Federation model

The Distributed Configuration Guide provides details about this model.

20 EMC Documentum Content Server Version 6.5, SP2 Installation Guide

Location for installing the relational database

EMC Documentum Content Server Version 6.5, SP2 Installation Guide 21

Username Content Server will use to connect to the

Size of repository to create

Location for storing the content files

22 EMC Documentum Content Server Version 6.5, SP2 Installation Guide

Name and ID to assign to the repository

Connection brokers to which to project Content Server

Before you install Content Server —

EMC Documentum Content Server Version 6.5, SP2 Installation Guide 23

Permit or require secure SSL connections

24 EMC Documentum Content Server Version 6.5, SP2 Installation Guide