EMC Documentum Content Server: Installation Guide 300 007 195-A01

EMC® Documentum®
Content Server
Version 6.5
Installation Guide
300007195–A01
EMC Corporation
Corporate Headquarters:
Hopkinton, MA 01748‑9103
1‑508‑435‑1000
www.EMC.com
Copyright © 1992‑ 2008 EMC Corporation. All rights reserved.
Published July 2008
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 ...................... 17
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 ........................................... 22
Username Content Server will use to connect to the database .................... 22
Size of repository to create ...................................................................... 23
Location for storing the content files ........................................................ 23
Name and ID to assign to the repository .................................................. 24
Connection brokers to which to project Content Server
information ............................................................................................ 24
Permit or require secure SSL connections ................................................. 25
Authenticate users .................................................................................. 25
Ports to reserve for Content Server use ..................................................... 26
Repository to use as the global registry .................................................... 27
Extended services products to license ...................................................... 28
Chapter 2 Preparing the Host for Content Server Installation ................................ 31

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

Table of Contents
Setting up the services file ....................................................................... 40
Chapter 3 Preparing the Database for Content Server Installation ........................ 43

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

Installation and configuration checklist ........................................................ 58
Installing Content Server software on a UNIX or Linux host .......................... 60
Installing Content Server software on a Windows host .................................. 63
Configuring Content Server and the repository on a UNIX or
Linux host .................................................................................................. 67
Running the administrative tool script manually .......................................... 72
Configuring Content Server and the repository on a Windows host ............... 73
Reviewing the Content Server installation logs ............................................. 79
Chapter 5 Completing the Installation ................................................................... 81

Running dm_root_task manually on UNIX or Linux hosts ............................ 81
Changing the default passphrase ................................................................. 82
Binding Content Server to a network card .................................................... 82
Configuring JBoss application servers for SSL............................................... 83
Changing the installation owner account...................................................... 83
Backing up key store files ............................................................................ 86
Starting Content Server and the connection broker........................................ 86
Adding users and groups to a repository ..................................................... 87
Enabling jobs after installation ..................................................................... 87
Enabling the purge audit job ................................................................... 87
Creating additional repositories or connection brokers .................................. 88
Chapter 6 Upgrading Content Server ..................................................................... 89

Upgrade checklist ....................................................................................... 89
Migrating the database to UTF–8 ............................................................. 93
The database_refresh_interval key ........................................................... 93
4 EMC Documentum Content Server Version 6.5 Installation Guide

Table of Contents
Oracle optimization setting ..................................................................... 93

Completing workflows before an upgrade ............................................... 93
Upgrading sequence considerations ......................................................... 94
Upgrading the Content Server software ....................................................... 95
Adding descriptors to a global registry ........................................................ 97
Chapter 7 Uninstalling Content Server ................................................................ 101

Order of uninstalling components ............................................................. 101
Deleting a repository ................................................................................ 102
Deleting a connection broker ..................................................................... 103
Uninstalling the Content Server software ................................................... 104
Chapter 8 Installing Documentum Messaging Services ....................................... 107

Configuration requirements ...................................................................... 107
The dms.properties file ............................................................................. 108
File administration ............................................................................... 108
Changing the JMX user password .......................................................... 108
Specifying the cleanup interval for expired messages .................................. 109
Preinstallation requirements...................................................................... 109
Installing DMS ......................................................................................... 110
Uninstalling DMS ..................................................................................... 113
On Windows hosts ............................................................................... 113
On UNIX and Linux hosts ..................................................................... 114
Starting and stopping DMS ....................................................................... 115
On Windows hosts ............................................................................... 115
On UNIX and Linux hosts ..................................................................... 115
Chapter 9 Installing Remote ContentFile Servers in Distributed

Configurations .................................................................................... 117
Installing and configuring the content‑file server ........................................ 118
Upgrading a distributed configuration ....................................................... 120
Deleting a content‑file server ..................................................................... 123
Chapter 10 Installing Content Server with Microsoft Cluster Services .................. 125
Overview ................................................................................................. 125
Choosing a configuration .......................................................................... 126
Configuring an active/passive cluster ......................................................... 129
Creating the cluster resource group ....................................................... 129
Installing Content Server software on the nodes ..................................... 130
Configuring Content Server .................................................................. 130
Configuring the connection brokers ....................................................... 137
Creating additional cluster resources ..................................................... 137
Verifying failover .................................................................................. 139
Configuring an active/active cluster ........................................................... 139
Creating the first cluster resource group................................................. 140
Installing Content Server software on the hosts....................................... 140
Configuring Content Server on the first and second nodes ...................... 140
Configuring the second cluster resource group ....................................... 140

Table of Contents
Modifying server.ini and dfc.properties ................................................. 141

Creating the connection broker generic service resource .......................... 141
Creating the Content Server service resource .......................................... 142
Verifying failover .................................................................................. 143
Upgrading Content Server installed with Cluster Services ........................... 143
Chapter 11 Configuring Multiple Content Servers on a Single Host for a

Particular Repository .......................................................................... 145
Windows hosts ......................................................................................... 145
UNIX hosts .............................................................................................. 147
Chapter 12 Creating a repository copy to test an upgrade .................................... 151

Creating the test environment ................................................................... 151
Precopying tasks ...................................................................................... 152
Copying a repository ................................................................................ 153
Appendix A Required Environment Variables for UNIX and Linux .......................... 157
Appendix B Content Server Installation Directories and Repository
Configuration Scripts .......................................................................... 163
Content Server installation file structure .................................................... 163
_uninst ................................................................................................ 164
data ..................................................................................................... 164
dba ...................................................................................................... 164
fulltext ................................................................................................. 164
product ................................................................................................ 165
server_uninstall .................................................................................... 165
share ................................................................................................... 165
Additional directories ........................................................................... 166
Scripts run during installation or upgrade .............................................. 169
Configuration objects ............................................................................ 173
Appendix C Troubleshooting a Content Server Installation .................................... 175

Identifying the problem and resolution ...................................................... 175
Error during session construction on Solaris‑DB2 ................................... 178
Recovering from a failed repository configuration or upgrade ..................... 179
Enabling tracing in repository configuration scripts .................................... 180
Recovering from a stalled Content Server upgrade...................................... 180
Appendix D Object Type Categories for Oracle Database Storage ......................... 183
Type categories for tablespace specifications............................................... 183
Type categories for extent allocation .......................................................... 184
Object types categorized as large ........................................................... 184
Object types categorized as small ........................................................... 185
Object types categorized as default ........................................................ 185
Appendix E Defining Oracle or DB2 Database Parameters for Repository

Tables ................................................................................................. 187
Defining the tablespace ............................................................................. 188
FUNCTION_SPECIFIC_STORAGE ....................................................... 188
TYPE_SPECIFIC_STORAGE ............................................................. 188
Defining the Oracle extent sizes ............................................................. 189

Table of Contents
Changing storage parameters for individual object types on

Oracle .................................................................................................. 190
Changing storage parameters for categories of types on Oracle ................ 191
User‑defined object types ...................................................................... 192

Table of Contents
List of Figures
Figure 1. Content Server repository structure ................................................................. 14

Figure 2. Basic installation model and component installation order ................................ 16
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 ........................................................................................... 21
Figure 8. Active/passive cluster ................................................................................... 127
Figure 9. Active/active cluster...................................................................................... 128

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

Table 2. General database installation and configuration checklist .................................. 43
Table 3. Oracle database installation and configuration checklist .................................... 44
Table 4. DB2 database installation and configuration checklist ...................................... 45
Table 5. SQL Server database installation and configuration checklist ............................ 45
Table 6. Sybase database installation and configuration checklist ................................... 46
Table 7. Content Server installation and configuration checklist ..................................... 58
Table 8. Content Server upgrade checklist .................................................................... 90
Table 9. Parameters required by dm_acs_install.ebs script ........................................... 122
Table 10. Precopying tasks .......................................................................................... 152
Table 11. Required environment variables .................................................................... 157
Table 12. Subdirectories created during installation ...................................................... 166
Table 13. Repository configuration scripts .................................................................... 169
Table 14. Troubleshooting checklist .............................................................................. 176

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
July 2008 Initial publication for version 6.5

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 17
• 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 content repository and provides content
management capabilities. The content repository consists of data stored in distinct
physical sources. 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.
The repository also can include a set of fulltext indexes to enable a content‑based
search of the repository. The Content Server Fulltext Indexing System Installation and
Administration Guide contains information about this option. Figure 1, page 14 shows the
basic structure of a Content Server repository.
Figure 1. Content Server 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 17

• 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 content 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 16 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.

Singlerepository 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.
Singlerepository 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 21 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 22
• Username Content Server will use to connect to the database, page 22
• Size of repository to create, page 23
• Location for storing the content files, page 23
• Name and ID to assign to the repository, page 24
• Connection brokers to which to project Content Server information, page 24
• Permit or require secure SSL connections, page 25
• Ports to reserve for Content Server use, page 26
• Repository to use as the global registry, page 27
• Extended services products to license, page 28

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. 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 48.
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 Adminsitration 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 40 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 8489.
• 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.

• Collaborative Edition introduces rich‑text editing, notes, discussion threads, and

rooms in support of collaboration.
• 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 33
• Internationalization settings, page 34
• Setting up user accounts, page 35
• Preparing UNIX and Linux hosts, page 38
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 Content Server Release Notes

configuration.
Validate the operating system Content Server Release Notes

and operating system‑database
configuration combination.

Preparing the Host for Content Server Installation
Task Resource Value
Ensure that the Content

Server host’s video card uses a
minimum of 256 colors.
On UNIX and Linux hosts, Shared memory and
ensure that at least 2 MB of semaphore requirements,
shared memory is allocated and page 38
that semaphores are enabled.
On Windows, obtain the name SMTP hostname:

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

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

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

and groups on the operating page 35
system and in the database.
On UNIX and Linux, create any Setting up the services file,

required services file entries. page 40

Task Resource Value
On UNIX and Linux, optionally Preparing UNIX and Linux

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

root password. __________
On Windows, determine the This domain is the default domain name

Windows domain where users domain if users do not __________
are authenticated. specify a Windows domain
when they connect. Choose
the domain with the largest
number of users.
Determine the port numbers to The default connection port number:

be used by the repository and broker port is 1489. If __________
connection broker. you are using the default
port number, ensure that port number:
the next port number __________
(1490) is available for use
because the connection
broker requires that two
ports be reserved.Setting
up the services file, page
40 provides information on
port numbers under UNIX.
Determine the hostname where hostname:
the 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, 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 47 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
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 36.
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.
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 groups 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.


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 43
• Requirements for all databases, page 47
• Oracle requirements, page 49
• SQL Server requirements, page 51
• Sybase requirements, page 52
• DB2 requirements, page 54
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 Content Server Release Notes
and the combination of
operating system database
configuration.

Preparing the Database for Content Server Installation
Task Resource Value

If you are doing a custom Database documentation datafile size:
Content Server installation, __________
determine the datafile size. In
a custom installation you can
change the default values. An
express installation uses the
default values.
If you are doing a custom Database documentation log file size:
Content 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 “Database administrator database
administrator name and account, page 49” and the administrator name:
password. database administrator __________
database
administrator
password:
__________
Install the database instance Database documentation
with 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 Oracle documentation
an existing Oracle instance to
UTF‑8 code page.

Task Resource Value

Decide whether to configure Oracle documentation
the database for improved
performance. You need to do
this before starting Content
Server.
Set up the networking “Oracle requirements, page
parameters. 49”
Ensure that the database aliases Oracle documentation and
are in the tnsnames.ora file on “Entries in tnsnames.ora
the Content Server host. file, page 50”
Ensure that the Oracle Listener Oracle documentation

is running on the Oracle host.
Ensure that the Oracle “Oracle requirements, page
optimizer meets 49”
EMC Documentum
recommendations.
Table 4. DB2 database installation and configuration checklist
Task Resource Value

Decide whether to configure DB2 documentation and
the database for improved “DB2 requirements, page
performance. You need to do 54”
this before starting Content
Server.
Obtain the database alias name. “DB2 requirements, page database alias name:
54” __________
Ensure that the DB2 clients are “DB2 requirements, page
installed on the Content Server 54”
host.
Table 5. SQL Server database installation and configuration checklist
Task Resource Value

Configure open database “Configuring an ODBC
connectivity (ODBC). Data Source for SQL Server,
page 51”

Task Resource Value

Use a full SQL Server SQL Server documentation
installation by 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 “SQL Server requirements,
owner and installation owner page 51”
meet the requirements.
Install the SQL Server client on SQL Server documentation
the Content Server host.
If SQL Server is installed SQL Server documentation
remotely, install Microsoft Data
Access Components 2.71 on the
Content Server host.
Install SQL Server for “SQL Server requirements,
internationalization. page 51”
Table 6. Sybase database installation and configuration checklist
Task Resource Value

In the $SYBASE/server_name.cfg “Sybase requirements,
file, set the system parameters page 52“ and Sybase
number of open objects, documentation.
number of open indexes, and
number of locks.
Set the page size to a minimum Sybase documentation and
size of 8 KB. “Sybase requirements, page
52”

Task Resource Value

Ensure that the Sybase version Sybase documentation
is at least 12.5.
Ensure that the Sybase directory Sybase documentation and
structure is correct. “Sybase requirements, page
52”
Requirements for all databases

Database tables store attribute values for each object in the Content Server 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 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 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 should have permission to create any view, resource, and
unlimited tablespace. The tablespace created by the repository owner for tables or
indexes should be designated the default, while the standard Oracle temporary
tablespace should 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 should 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 48, 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 = 25000
number of user connections = 200
procedure cache size = 48000
number of open data partitions =2500
Note: For Sybase 15.0, increase the number of open data 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
• A large DB2 repository has an initial datafile size of 800 MB and an initial index

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 58
• Installing Content Server software on a UNIX or Linux host, page 60
• Installing Content Server software on a Windows host, page 63
• Configuring Content Server and the repository on a UNIX or Linux host, page 67
• Configuring Content Server and the repository on a Windows host, page 73
• Reviewing the Content Server installation logs, page 79

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 7. 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 23
Decide whether to enable Extended services products
extended services products, such to license, page 28
as:
• Trusted Content Services
• Content Services for EMC
Centera
• SnapLock
• High‑Volume Server
• Content Storage Services
• Content Collaborative Services
• Retention Policy Services
• Physical Records Manager
Review the Content Chapter 3, Preparing the
Server‑specific information Database for Content Server
for the database. Installation.
For SQL Server, obtain the ODBC Configuring an ODBC Data
data source name Source for SQL Server,
page 51and the database
vendor’s documentation

Task Resource Value

Determine the installation owner Setting up the installation installation owner
username and password. owner account, page username:
35 and consult 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.
Choose the repository ID. The repository ID can be repository ID:
any 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, repository owner
(database user) and password. page 35 name:
__________
repository
password:
__________
Obtain the database administrator Database administrator database
name and password. account, page 49 and the administrator name:
database administrator __________
database password:
__________

Task Resource Value

Create an estimate of the Size of repository to create, repository size:
repository size. page 23 __________
If you assign the Content Server • Content Server
file store to a shared folder on the and the file store
network with a UNC path, you need to be on the
need to meet the criteria listed in same domain
the Value column.
• 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 35 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 8489. 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 81.
22. Click Finish to exit the Content Server installation program.
Installing Content Server software on a

Windows host
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 35 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 Content Server installation directory (C:\Program
Files\Documentum) 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 DFC
installation directory (C:\Program Files\Documentum,) 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 Nextor 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
requires that two port numbers be reserved.
You can configure additional connection brokers by using the Content Server
configuration wizard.
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 key, and click Next.
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 8489. The selected
port must not be used by another application. A total of 20 ports starting at port
number 8489 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 73 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 72 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 72.
14. To enable Content Storage Services, select the check box, type the license key, and
click Next.
15. To enable Collaborative Services, select the check box, type the license key and click
Next.
16. To enable Retention Policy Services, select the check box, type the license key, and
click Next.
17. To enable Federated Records Services, select the check box, type the license key,
and click Next.
18. To enable Records Manager, select the check box, type the license, and click Next.
19. To enable Physical Records Manager, select the check box, type the license, and
click Next.
20. Click Next to accept the default data directory location or browse for a different
location. The default location is C:\Dcoumentum\data.

21. Click Next to accept the default share directory location or type a new location.
Express configuration uses the default directory C:\Documentum\share.
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.
22. To enable data partitioning, select the check box and click Next.
23. Provide the repository information.
a. Type the name of the repository. Name and ID to assign to the repository, page
24 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.
24. Click Next.
25. Select whether to create a new database user account and storage areas or use an
existing user account and storage, and click Next.
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.
26. 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 48.
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.
27. If you chose to create a new database user account, provide database connection
information.
drop‑down list:
b. Type the database user’s name.
This user becomes the repository owner, and must have the privileges identified
in Repository owner account, page 48.
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.

28. 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.
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. Click Next.

The configuration program runs the repository configuration scripts based on the
settings you provided.
32. 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 27 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.
33. 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.

34. 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.
35. Click Next.
36. 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.
37. 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.
38. Click Finish.
39. 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:
dmbasic f$DOCUMENTUM\product\6.5\install\admin\toolset.ebs
P repository_name $DOCUMENTUM\product\6.5\install\admin
database_connection_string e ToolSetup
• $DOCUMENTUM is the path to the installation directory.
• repository_name is the name of the repository.
• database_connection_string is the connection string to the database.
For example, if the path to $DOCUMENTUM is C:\Documentum, the
repository name is TestARepository, and the database connection string is
connect1.documentum.com:
dmbasic
f c:\DOCUMENTUM\product\6.5\install\admin\toolset.ebs P TestArepository
c:\DOCUMENTUM\product\6.5\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, navigate to the correct version of the Content Server product, 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 .
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 72.
13. Configure a repository.
14. To enable Content Storage Services, select the check box, type the license key, and
click Next.
15. To enable Collaborative Services, select the check box, type the license key and click
Next.
16. To enable Retention Policy Services, select the check box, type the license key, and
click Next.
17. To enable Federated Records Services, select the check box, type the license key,
and click Next.
18. To enable Records Manager, select the check box, type the license, and click Next.
19. To enable Physical Records Manager, select the check box, type the license, and
click Next.
20. Click Next to accept the default data directory location or browse for a different
location. The default location is C:\Dcoumentum\data.
21. Click Next to accept the default share directory location or type a new location.
Express configuration uses the default directory C:\Documentum\share.
The share directory is where client products, sample code, and libraries are stored.
environment variable. This environment variable sets the directory into which EMC
Documentum Foundation Classes and other components are installed.
22. To enable data partitioning, select the check box and click Next.
23. Provide the repository information.
a. Type the name of the repository. Name and ID to assign to the repository, page
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.
24. Select whether to create a new database user account and storage areas or use an
existing user account and storage, and click Next.
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.
drop‑down list:
• 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 48.
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.
drop‑down list:
• 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.
and click Edit. When you have saved the file, click Next.
27. For custom configuration only, accept or modify Content Server initialization values.
Express configuration uses the default initialization file.
28. Click Next.
The installation program runs the repository configuration scripts based on the
settings you provided.

29. 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.
30. Optionally, you can edit a tablespace script by clicking Edit.
31. Optionally, you can edit an initialization file by clicking Edit.
Caution: Errors in the server.ini file can cause problems with Content Server
startup.
32. 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.
33. Decide whether to designate the current repository as a global registry.
and click Next.
and click Next.
dm_bof_registry.


CONTINUE.
35. For custom configuration only, accept or modify the repository configuration scripts.
Express configuration runs the scripts without modification.
click Next.
37. 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.
38. Click Finish.
39. 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 81
• Running the administrative tool script manually, page 72
• Changing the default passphrase, page 82
• Changing the installation owner account, page 83
• Backing up key store files, page 86
• Starting Content Server and the connection broker, page 86
• Adding users and groups to a repository, page 87
• Enabling jobs after installation, page 87
• Creating additional repositories or connection brokers, page 88
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
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. Stop all connection brokers on the host.
5. 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.
6. 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.
7. Edit the Registryto 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.
8. 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.
9. 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.
10. 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.

11. Update the r_install_owner and r_install_domain parameters in the server_config

object to reflect the new installation owner.
12. 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 88 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,:
• 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 89
• Upgrading the Content Server software, page 95
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 8. Content Server upgrade checklist
Task Resource Value

Review Chapter 2, Chapter 2, Preparing the
Preparing the Host for Host for Content Server
Content Server Installation, Installation, and Chapter 3,
and Chapter 3, Preparing Preparing the Database for
the Database for Content Content Server Installation.
Server Installation
Review the Content Server Content Server Release Notes
Release Notes
Review the System Upgrade System Upgrade and
and Migration Guide. Migration Guide.
If you are installing Content Server Fulltext
the fulltext indexing Indexing System Installation
components, review the and Administration Guide
Content Server Fulltext
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
extended services, such as: to license, page 28
• Retention Policy Services
• Trusted Content Services
• Content Services for
EMC Centera
• Content Storage Services
• Content Collaborative
Services
• Physical Records
Manager

Task Resource Value

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 Content Server
consistency checker script Administration Guide
and correct any errors you and Chapter 6, Upgrading
find. Content Server
Shut down the repository Content Server
and all servers running Administration Guide
against the repository.
Shut down any local Content Server
connection brokers. Administration Guide
On Windows, set the
service representing
the repository you are
upgrading to.
On UNIX and Linux, Preparing UNIX and Linux
create the new installation hosts, page 38
directory for the upgraded
installation under the
$DOCUMENTUM/product
directory (the new
$DM_HOME directory).

Task Resource Value

modify the DM_HOME hosts, page 38
variable in the installation
owner’s .cshrc or
.profile file to point
to $DOCUMENTUM/
product/version_number.
modify the library path hosts, page 38
variable in 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
owner username and owner account, page 35, username:
password and consult the database __________
administrator.
installation owner
password:
__________
On UNIX and Linux, UNIX and Linux root password:
determine the root documentation
password __________
This is the operating system

root password. The root
password is required to
complete the upgrade.
Determine the names of repository name:
the repositories you are
upgrading. __________
Determine the Content Content Server version:
Server version from which __________
you are upgrading.

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 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.
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 101
• Deleting a repository, page 102
• Deleting a connection broker, page 103
• Uninstalling the Content Server software, page 104
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 102 and Deleting a connection
broker, page 103.
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 107
• The dms.properties file, page 108
• Specifying the cleanup interval for expired messages, page 109
• Preinstallation requirements, page 109
• Installing DMS, page 110
• Uninstalling DMS, page 113
• Starting and stopping DMS, page 115
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 (8489 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
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.
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 8489.
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 ContentFile Servers
in Distributed Configurations
This chapter provides instructions for installing and configuring content‑file servers (remote Content
Servers) in distributed content configurations.
If you are creating a new single‑repository distributed 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 118
• Upgrading a distributed configuration, page 120
• Deleting a content‑file server, page 123
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

Installing Remote ContentFile Servers in Distributed Configurations
When a content‑file server is created for a distributed 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 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 configuration must be set to the same UTC time.
A repository that uses a distributed 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 configurations, in federations, or where replication is used.
Caution: After a repository has been configured to use distributed 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 contentfile

server
Use these instructions to install and configure the content‑file server.
To configure the contentfile 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
ACS server, do one of the following:
• On Windows hosts, restart after the installation.
• On UNIX or Linux distributed configurations, use Documentum Administrator
to set the Get method for each component of the distributed store to Surrogate
Get.
Upgrading a distributed configuration

This section describes the overall procedure for upgrading an existing distributed
configuration.
Use these guidelines in deciding how to upgrade a distributed 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 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 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 configuration:

1. On the primary host, use the instructions in Upgrading the Content Server software,
page 95, to upgrade Content Server, connection brokers, and repository.
2. On each remote host, use the instructions in Upgrading the Content Server software,
page 95, 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 9, page 122. 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 9. 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 contentfile server

Use these instructions to delete a content‑file server and its software installation in a
distributed 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 103.
To delete a contentfile 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 125
• Choosing a configuration, page 126
• Configuring an active/passive cluster, page 129
• Configuring an active/active cluster, page 139
• Upgrading Content Server installed with Cluster Services, page 143
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,

Installing Content Server with Microsoft Cluster Services
all resources form a virtual server that can move from one physical server to another to
provide failover support.
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 127 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 128 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 58.

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 129
• Installing Content Server software on the nodes, page 130
• Configuring Content Server, page 130
• Configuring the connection brokers, page 137
• Creating additional cluster resources, page 137
• Verifying failover, page 139
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

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.
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 key, and click Next.
b. To enable Collaborative Services in the repository, select the check box, type
c. To enable Retention Policy Services in the repository, select the check box, type
d. To enable Federated Records Services in the repository, select the check box,
type the license key, and click Next.
e. To enable Records Manager in the repository, select the check box, type the
license key, and click Next.
f. To enable Physical Records Manager in the repository, select the check box,
type the license key, and click Next.
The Data Directory dialog box appears.
g. 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.
h. Click Next to accept the default share directory location or browse for a new
location.
The share directory is where client products, sample code, and libraries are
stored.
environment variable. This environment variable sets the directory into which
EMC Documentum Foundation Classes and other components are installed.
i. 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.
j. Type the name of the repository. Name and ID to assign to the repository, page
Note: If you are installing on the second node, use the same repository name
you used for the first node.
k. Type the repository ID. Name and ID to assign to the repository, page 24 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.
l. Type a description for the repository.
m. Select the repository size.
n. Select the authentication domain.
o. 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.
p. 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.
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.
and click 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.
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.
and click Next.
and click Next.
dm_bof_registry.
CONTINUE.
23. Accept or modify the repository configuration scripts. Express configuration runs
the scripts without modification.
24. Click Next.
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. Shut down Content Server and the connection broker.
31. Move the cluster group to the second node.
32. Use the instructions in Installing Content Server software on the nodes, page 130, and
Configuring Content Server, page 130, to repeat the installation and configuration
procedures for the second node.
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 140

• Installing Content Server software on the hosts, page 140
• Configuring Content Server on the first and second nodes, page 140
• Configuring the second cluster resource group, page 140
• Modifying server.ini and dfc.properties, page 141
• Creating the connection broker generic service resource, page 141
• Creating the Content Server service resource, page 142
• Verifying failover, page 143
Creating the first cluster resource group

Create the first cluster resource group by following the instructions in Creating the
cluster resource group, page 129.
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 130 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 129.

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, singlerepository 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 95.
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 95.
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.
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 145
• UNIX hosts, page 147
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 Internet application programming
interface (IAPI) or Documentum Administrator and create a new server config object.
For example, if the existing server config object is called caruso, call the new server
config object caruso1.
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.

Configuring Multiple Content Servers on a Single Host for a Particular Repository
c. Open the server1.ini file and add these lines:

service=caruso1
server_config_name=caruso1
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 IAPI or Documentum
Administrator and create a new server config object.
For example, if the existing server config object is called caruso, call the new server
config object caruso1.
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
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/ .*[: AZaz]//'
to
DM_PID=`./iapi caruso.caruso1 U$DM_DMADMIN_USER P e << EOF |
grep 'root_pid' | sed e 's/ .*[: AZaz]//'
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 151
• Precopying tasks, page 152
• Copying a repository, page 153
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,

Creating a repository copy to test an upgrade
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.
Precopying tasks
Before you create the repository copy, complete these tasks and note any appropriate
values in the Value column:
Table 10. 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 Consult the repository ID: ____________
the server.ini file. repository
administrator.
Obtain the repository owner’s Consult the repository owner: ____________
name and password. repository
administrator.
Create a database instance Consult the DBA.
separate from the database
instance used by the production
repository.
Obtain connection information Consult the DBA connection: ____________
for the alternative database and database
instance. documentation
Identify a target host on which target host: ____________
to create the repository copy
Obtain the system or Consult the DBA. admin user name: ____________
administrator username
and password for the database.
Note the drive on which the drive: ____________
production repository resides.

Task Resource Value

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 11. 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

Required Environment Variables for UNIX and Linux

LC_ALL C
Caution: If this value is

not set correctly, the Java
method server will fail.
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
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 163
• Scripts run during installation or upgrade, page 169
• Configuration objects, page 173
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

Content Server Installation Directories and Repository Configuration Scripts
_uninst
This directory contains the Content Server uninstaller.
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 12, page 166 .
Table 12. 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
WebCache 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
* Optional IAPI and IDQL 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 13. Repository configuration scripts
Script name Location Purpose Other

headstart.ebs $DM_HOME/ Loads the initial
install/admin default objects for
the repository.
Creates mount
point objects,
location objects, file
store objects, and
method objects.


dm_apply_formats. $DM_HOME/bin Creates or updates
ebs format objects,
which are required
for content file
operations.
dm_cas_install.ebs $DM_HOME/ Creates a method,
install/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/ Loads methods Run only during an
install.ebs install/admin that are used upgrade.
for converting
routers to workflow
template.
templates.ebs $DM_HOME/ Creates default
install/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/ Creates folders
install/desktop_ required by
client Documentum
Desktop and
installs the default
SmartList .
disable_fulltext_ $DM_HOME/ Run only during an
jobs.ebs install/admin upgrade.


dfc.ebs $DM_HOME/ Loads default
install/admin objects required by
the Documentum
Foundation
Classes.
Dfc_bof2.ebs $DM_HOME/ Creates the types
install/admin for 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/ Creates types,
install/admin relation types, acls,
and repository
folders for
DFC evaluation
of validation
expression
constraints in Java.
dm_bpmmodules_ $DM_HOME/
install.ebs install/admin
createMethod‑ $DM_HOME/
ServerObject.ebs install/admin
csec_plugin_ $DM_HOME/ Upgrades the Run only during an
upgrade_53.ebs install/admin plugin for upgrade.
using content‑
addressable storage
areas.
toolset.ebs $DM_HOME/ Installs repository
install/admin administration
tools.
dm_bpm_install. $DM_HOME/
ebs install/admin


dm_wfTimer_ $DM_HOME/ Converts workflow Run only during an
upgrade.ebs install/admin pre‑ and post‑ upgrade.
timers 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/
lifecycle.ebs install/admin
create_fulltext_ $DM_HOME/ Creates repository
objects.ebs install/admin objects related to
fulltext indexing.
dm_ldap_install. $DM_HOME/ Creates or
ebs install/admin upgrades the ldap
config object type
and upgrades any
existing ldap config
objects.
dm_storageser‑ $DM_HOME/
vices_install.ebs install/admin
dm_emailTem‑ $DM_HOME/
plate_install.ebs install/admin
dm_xml_install.ebs $DM_HOME/ Installs object types
install/admin and formats for
XML files.
dm_gwm_install. $DM_HOME/bin Executes scripts
ebs that install
workflow‑related
types, methods,
folders, and jobs.
upgrade_java_ $DM_HOME/ Upgrades existing
methods_51.ebs install/tools Java methods.


ci_schema_install. $DM_HOME/ Installs the object
ebs install/tools types used by
Documentum
Content
Intelligence
Services.
display_config_ $DM_HOME/ Configures the
setup.ebs install/tools repository for
the Documentum
Offline Client.
offline_config_ $DM_HOME/ Migrates offline
setup.ebs install/tools configuration
settings from the
offline_config
object to the
docbase config
object.
upgrade_ $DM_HOME/ Run only during an
contentreplication_ install/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 175
• Recovering from a failed repository configuration or upgrade, page 179
• Enabling tracing in repository configuration scripts, page 180
• Recovering from a stalled Content Server upgrade, page 180
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 79 provides details.
Table 14, page 176 can help you identify the problem you are experiencing, a possible
cause, and recommended resolution.ʺ

Troubleshooting a Content Server Installation
Table 14. Troubleshooting checklist
Symptom Cause Fix

Content Server installation You are trying to install or Connect using the
or upgrade fails upgrade the Content Server installation owner account.
but you are not connected
as the installation owner.
The environment variables
are not set correctly.
While installing a Three possible causes of To fix these three causes:
repository, you see an error this error:
message that indicates that 1. Make the installation
the user is not a valid UNIX 1. The installation owner owner group the
user: account does not have installation owner’s
the installation owner primary group.
Configuration of
group designated as
the docbase fails 2. Set the shared library
the user’s primary
with the message path environment
group. Group
'user must be a variable correctly.
ownership of the
valid unix user' Appendix A, Required
Documentum binaries
exec(): 0509036 Environment Variables
is incorrect.
Cannot load program for UNIX and
/u01/app/documentum/ 2. The shared library path Linux provides
product/5.2/bin/ environment variable information on setting
dmisvaliduser is not set correctly. environment variables
because of the
3. On DB2, the 3. Chapter 3, Preparing
following errors:
$DB2_BASE the Database for
0509150 Dependent
environment variable Content Server
module libldap50.so
is not set correctly. Installation and the
could not be loaded.
documentation for
0509022 Cannot load
DB2 contain more
module libldap50.so.
information
0509026 System
error: A file or
directory in the
path name does not
exist.
Content Server upgrade There might be a cyclic Recovering from a stalled
appears unresponsive. group. Content Server upgrade,
page 180 contains details.

Symptom Cause Fix

On Windows hosts, you The correct video driver Review the hardware and
see the following error for the video card is not software configuration of
during installation: installed on the host. the host.
Could not initialize
interface awt
exception
ExceptionInitializationError
You see the following error The dm_ContentRepli‑ Delete the following
during an upgrade of an cation method has some entry from the
older repository: parameter arguments left dm_ContentReplication
over from EDMS98. method:
Failed to retrieve
serverconfig serverconfigname
object with name [domain\]user,passwd
<serverconfigname>.
***Failed to encrypt
passwords for
docbase ec_epac,
status 1057226550
**Operation failed
** [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 Invalid Oracle views Make the views valid
errors during upgrade belonging to types _sv, _sp, before upgrading Content
from 5.3 to 6.5 on Oracle _rv, and _rp. Server.
10:
A view in Oracle becomes To determine which views
Tue Feb 22 21:48:08 invalid when the base in the Oracle installation
2005 098000 tables it references are invalid, you can run
[DM_SESSION_I_ change (for example, the following query from
INIT_BEGIN]info: by adding/dropping a SQLPLUS logging in as the
"Initialize repository owner:

Symptom Cause Fix

dmContent." Tue Feb column, or dropping a select object_name,
22 21:48:08 2005 unique constraint index). object_type from
567000 [DM_SESSION_
user_objects where
I_INIT_BEGIN]info:
status='INVALID';
"Initialize
dmiSubContent." To recompile the views:
Tue Feb 22 21:48:08
2005 598000 ALTER VIEW view_name
[DM_TYPE_MGR_E_CANT_ COMPILE;
FIND_TABLE]error:
The Oracle‑supplied
"Failure to
package named
find table
DBMS_UTILITY has
dmi_subcontent_sv
a procedure named
as part of fetch of
COMPILE_SCHEMA. This
type dmi_subcontent:
procedure will compile
error from database
all stored code, views,
system is ORA24372:
and so on, for the schema
invalid object for
provided. The best way
describe" Tue Feb 22
to compile all database
21:48:08 2005 598000
objects that are invalid
[DM_SESSION_E_INIT_
is to use a script in the
FAILURE1]error:
$ORACLE_HOME/rdbms/
"Failure to complete
admin directory named
dmiSubContent
utlrp.sql. This script
initialization."
finds all objects in the
You might also see this
data dictionary that are
message:
invalid and compiles them.
ORA24372: invalid This script is typically
object for describe mentioned in patch notes
but you can use it any time
a schema change occurs.
Error during session construction on SolarisDB2

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 79 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 183
• Type categories for extent allocation, page 184
The categories for each context are not the same. Type categories for tablespace specifications, page
183, helps you to find the categories for tablespace determination and to Type categories for extent
allocation, page 184, 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.

Object Type Categories for Oracle Database Storage
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
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
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
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_ dmc_wfsdrp_boolean
relation
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_ dmc_wfsdrp_string
boolean
dmc_module dmc_wfsd_element_date dmc_workqueue
dmc_preset_info dmc_wfsd_element_ dmc_workqueue_policy
double
dmc_preset_package dmc_wfsd_element_ dmi_autittrail_attrs
integer
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 Oracle or DB2 Database Parameters for Repository Tables
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.
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
Userdefined 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, 35
installation owner, 35 Collaborative Services, 29
repository owner, 22, 37, 48 common directory, 166
acs.properties file config directory, 164
administration, 108 configuration
active/active clusters, 141 basic server installation, 169
connection broker generic application default, 169
resources, 141 file locations, 165
Content Server service resources, 142 objects, described, 173
described, 127, 139 overview, 174
first cluster resource group, 140 requirements, 39
repository configuration, 140 configuration decisions
server.ini file, 141 repository size, 23
verifying failover, 143 configuring
active/passive clusters repositories, 67, 73
configuring, 129 configuring Content Server, 21
configuring the repository, 130 CONNECT privileges, 49
connection broker configuration, 137 connecting to database, 22
creating resource groups, 129 connection broker
creating resources, 137 required ports, 26
described, 126 connection brokers
installing Content Server, 130 described, 15
verifying failover, 139 generic application resources, 141
administrative tool scripts, 72 in resource groups, 126
aek.key file, 151 Microsoft Cluster Services, 137
Content Server
Collaborative Services, 29
B configuration, 21
backing up key store files, 86 connection types, 25
Content Storage Services, 28
in resource groups, 126
C installation owner, 35
ci_schema_install.ebs script, 173 internationalization, 34
client connections, 25 Retention Policy Services, 29
clients directory, 166 service resource, 142
cluster resource groups Trusted Content Services, 28
creating, 129 uninstalling, 104
resources, 129 uninstalling Content Server, 101 to
cluster resources 103
creating, 137 Content Services for retention type store

Index
described, 28 log, 164

Content Storage Services, 28 product, 163
content‑addressed storage, 28 required for installation, 39
copying repositories, 151 SDK, 166
create_fulltext_objects.ebs, 172 share, 165
CSEC, see Content Services for retention temp, 166
type store version, 39
csec_plugin_upgrade_53.ebs, 171 disks, shared, 129
cyclic groups, 180 display_config_setup.ebs script, 173
distributed configurations
installation requirements, 118
D shared content model, 118
data directories, described, 23, 164 upgrading, 120
database UTC time, 118
code page, 47 distributed content, 121
database accounts, 22 dm_apply_formats.ebs script, 170
database location, 128 dm_cas_install.ebs, 170
database requirements dm_change_password, 39
repository owner, 37, 48 dm_check_password, 39
database_refresh_interval key, 93 dm_gwm_install.ebs script, 172
databases DM_HOME environment variable, 39,
DB2, 54 165
installation location, 22 dm_ldap_install.ebs script, 172
Oracle requirements, 49 dm_root_task script, 39
requirements, 47 dm_routerConv_install.ebs script, 170
requirements for upgrade, 93 dm_wfTimer_upgrade.ebs, 172
SQL Server requirements, 51 dm_xml_install.ebs script, 172
Sybase, 52 docu, 24
UTF‑8, 93 Documentum Administrator
Windows requirements, 48 adding groups, 87
DB2 Documentum Content Intelligence
current configuration, 55 Services, 173
environment variables, 54 DOCUMENTUM environment
performance wizard, 54 variable, 39
repository owner requirements, 49 Documentum Foundation Classes
requirements, 54 dfc.ebs script, 171
dba directory, 164 Documentum Offline Client, 173
dd_populate.ebs script, 173
desktop_client.ebs script, 170
dfc.ebs script, 171 E
directories EMC Documentum Site Caching
clients, 166 Services, 118
common area, 166 EMC Documentum Web Publisher, 118
config, 164 enabling repository configuration script
content storage, 129 tracing, 180
data, 23, 164 environment variables, 39
dba, 164 DB2, 54
DM_HOME, 165 DM_HOME, 39
event subdirectory, 166 DOCUMENTUM, 39
events, 166 installation owner environment, 157

Index
LANG, 34 changing, 83
library path, 159 described, 35
ORACLE_HOME, 50 domains, 37
Sybase, 53 environment variables, 157
events subdirectory, 166 password, 36
exiting installation, 63 required permissions On UNIX and
external password checking, 37 Linux, 36
external password validation, 37 root account, 36
SQL Server, 37
Sybase requirements, 53
F uninstalling Content Server, 101 to
failover, 126 103
failover verification, 143 username, 36
failover, verifying, 139 Windows domain requirements, 37
files Windows requirements, 36
aek.key, 151 Windows rights, 36
initlora, 50 installation owner group, 37
services, 40 installing
spfile, 50 copying server software, 57
Sybase configuration, 53 sequence, 57
tnsnames.ora, 49 to 50 installing content server
required ports, 26
G installing Content Server
basic configuration for server, 169
generic application resources, 141
configuration requirements, 39
global registry
configuration scripts, 169
Collaborative Services, 29
configuring repositories, 130, 140
network locations, 27
connection brokers, 15
SBOs, 27
copying software, 60, 63
groups, 87
database, 54
installation owner, 37
DB2, 54
directory structure, 163
H environment variables, 157
hardware requirements, 31 exiting, 63
headstart.ebs script, 169 hardware requirements, 31
host locales, 34 Microsoft Cluster Services, 125
host preparation multiple servers on UNIX and
UNIX, 38 Linux, 145
hostname requirement, 34 multiple servers on Windows, 145
hosts, 34 preparing, 31
repository size, 23
typical configurations, 15
I UNIX group accounts required, 36
index agent internationalization, 34
required ports, 26 database code page, 47
index server server host code pages, 35
required ports, 26 SQL Server, 47
init.ora file, 50 Unicode, 47
installation owner, 37 UTF‑8, 93
case‑sensitivity of username, 36

Index
J object type categories, 183

Java method server ODBC configuration, 51
required ports, 26 offline_config_setup.ebs script, 173
JMX password, changing, 108 Oracle
CONNECT privileges, 48
database aliases, 50
K environment variables, 50
key store files, backing up, 86 MAX_COMMIT_PROPAGATION_
DELAY parameter, 50
optimizing, 50
L ORACLE_HOME, 50
LANG environment variable, 34 preinstallation requirements, 49
local administrators group, 36 Real Application Clusters, 50
local database installations, 22 repository owner requirements, 48
log directory, 164 repository sizes, 51
logs, server installation, 80 RESOURCE privileges, 48
TNS aliases, 50
M tnsnames.ora file, 50
ORACLE_HOME environment
Microsoft Cluster Services, 141
variable, 50
active/active clusters, 127, 129
order of uninstalling, 101
active/passive clusters, 126, 129
configuration options, 126
configuring active/active clusters, 139 P
configuring active/passive passwords, 36 to 37
clusters, 129 to 130 port numbers, 41
configuring connection brokers, 137 ports
configuring the repository, 140 native connections, 40
connection broker projection, 141 required, 26
Content Server service resource, 142 secure connections, 40
content storage directories, 129 postinstallation tasks
database location, 128 adding groups, 87
Documentum configurations, 126 adding users, 87
installation choices, 126 administrative tool script, 72
modifying server.ini file, 141 PURGE AUDIT, enabling, 87
preinstallation tasks, 128 reviewing server installation logs, 80
repository owner, 37 preinstallation requirements
resource groups, 126 database, 22
shared disks, 129 database administrator account, 49
user permissions, 129 database code page, 47
verifying failover, 143 DB2, 54
directories, 39
N DM_HOME, 39
environment variables, 157
native connections, 25, 40
hostname, 34
network cards, 34
hosts, 34
network location objects, 27
installation directory, 39
repository owner, 22, 48
O supported code pages, 35
object replication, 121 XWindows, 38

Index
product directory, described, 163 DB2, 49

PURGE AUDIT job, 87 described, 22, 48
Microsoft Cluster Services, 37
Oracle, 48
R password, 37
remote database installations, 22 RDBMS account, 22, 48
remote domains, 37 required Windows privileges, 49
replicate_bootstrap.ebs script, 170 SQL Server, 49
repositories username, 37
active/active clusters, 140 Windows, 37
active/passive cluster, 129 requirements
configuring, 67, 73, 130, 140 ports, 26
copying, 151 reserved terms, 24
global registry, 27 resource groups, 126
owner, 49 RESOURCE privileges, 49
services file entries, 40 Retention Policy Services, 29
size, 23 root account, 36
user authentication, 38 root password, 92
users, 38 root task, 39
repository
ID, 24
name, 24 S
repository configuration failure, 179 scripts
repository configuration scripts dm_root_task, 39
ci_schema_install.ebs, 173 repository configuration, 169
create_fulltext_objects.ebs, 172 server configuration, 136
csec_plugin_upgrade_53.ebs, 171 SDK directory, 166
dd_populate_install.ebs, 173 secure connections, 25, 40
desktop_client.ebs, 170 semaphore requirements, 38
dfc.ebs, 171 server installation logs, 80
display_config_setup.ebs, 173 server.ini file, 141
dm_apply_formats.ebs, 170 database_conn key, 50
dm_cas_install.ebs, 170 services file, 40
dm_gwm_install.ebs, 172 port numbers, 41
dm_ldap_install.ebs, 172 service name, 40
dm_routerConv_install.ebs, 170 share directory, described, 165
dm_wfTimer_upgrade.ebs, 172 shared content configurations, 118
dm_xml_install.ebs, 172 shared disks, 129
headstart.ebs, 169 shared memory requirements, 38
offline_config_setup.ebs, 173 size of repository, 23
replicate_bootstrap.ebs, 170 spfile, 50
templates.ebs, 170 SQL Server
toolset.ebs, 171 custom installation, 51
upgrade_java_methods_51.ebs, 172 enabling case‑sensitivity, 51
repository copies, 151 enabling row‑level locking, 51
repository federations internationalization, 47
upgrading, 120 ODBC configuration, 51
repository owner repository owner requirements, 49
database privileges, 48 requirements, 51
database requirements, 49

Index
stalled server upgrade, shared memory, 38

troubleshooting, 180 shells, 157
Sybase space available, 39
configuration file, 53 XWindows, 38
devices, 53 unsecure connections, 25
environment variables, 53 upgrade_java_methods_51.ebs script, 172
installation owner, 53 upgrading Content Server
requirements, 52 database_refresh_interval ey, 93
described, 89
distributed configurations, 120
T distributed content, 121
temp directory, described, 166 effects on system, 89
templates.ebs script, 170 object replication, 121
Terminal Services, 121 repository federations, 120
testing an upgrade, 151 testing, 151
tnsnames.ora file, 49 to 50 UTF‑8, 93
toolset.ebs script, 171 users, 87
troubleshooting authentication on Windows, 38
diagnosis, 175 UTC time, 118
enabling repository configuration UTF‑8 code page, 34
script tracing, 180
repository configuration failure, 179
stalled server upgrade, 180 V
Trusted Content Services verifying failover, 139, 143
described, 28 version directory, 39
port numbers, 40 virtual IP addresses, 126
services file, 40 virtual network hostnames, 126
U W
Unicode, 47 Windows
uninstalling Content Server, 104 installing multiple servers, 145
Content Server, 101 repository owner, 49
installation owner, 101 to 103 user authentication, 38
order, 101 Windows requirements
requirements, 101 to 103 database service, 48
UNIX installation owner account, 35
host preparation, 38 installation owner user rights, 36
installing multiple servers, 145 local administrators group, 36
UNIX requirements, 39 repository owner, 37
directories, 39 Terminal Services, 121
environment variables, 39, 157
installation owner account, 36
root account, 36
X
semaphores, 38 XWindows, 38
services file, 40

EMC Documentum Content Server: Installation Guide 300 007 195-A01

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

EMC Documentum Content Server: Installation Guide 300 007 195-A01

Uploaded by

Copyright:

Available Formats

EMC® Documentum®

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

EMC Documentum Content Server Version 6.5 Installation Guide 3

Setting up the services file ....................................................................... 40

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

Chapter 4 Installing Content Server ....................................................................... 57

Chapter 5 Completing the Installation ................................................................... 81

Chapter 6 Upgrading Content Server ..................................................................... 89

4 EMC Documentum Content Server Version 6.5 Installation Guide

Oracle optimization setting ..................................................................... 93

Chapter 7 Uninstalling Content Server ................................................................ 101

Chapter 8 Installing Documentum Messaging Services ....................................... 107

Chapter 9 Installing Remote Content­File Servers in Distributed

EMC Documentum Content Server Version 6.5 Installation Guide 5

Modifying server.ini and dfc.properties ................................................. 141

Chapter 11 Conﬁguring Multiple Content Servers on a Single Host for a

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

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

Appendix E Deﬁning Oracle or DB2 Database Parameters for Repository

6 EMC Documentum Content Server Version 6.5 Installation Guide

Changing storage parameters for individual object types on

EMC Documentum Content Server Version 6.5 Installation Guide 7

Figure 1. Content Server repository structure ................................................................. 14

8 EMC Documentum Content Server Version 6.5 Installation Guide

Table 1. Host preparation checklist............................................................................... 31

EMC Documentum Content Server Version 6.5 Installation Guide 9

10 EMC Documentum Content Server Version 6.5 Installation Guide

Purpose of the manual

EMC Documentum Content Server Version 6.5 Installation Guide 11

12 EMC Documentum Content Server Version 6.5 Installation Guide

Content Server and repository overview

EMC Documentum Content Server Version 6.5 Installation Guide 13

Metadata is stored in tables in a relational database as sets of attributes. A configurable

Figure 1. Content Server repository structure

A client application views the repository as a single repository whose implementation

Content Server installation models

14 EMC Documentum Content Server Version 6.5 Installation Guide

• Single‑repository model with content stored at primary site, page 17

Basic installation model

EMC Documentum Content Server Version 6.5 Installation Guide 15

Figure 2. Basic installation model and component installation order

Client applications communicate with Content Server through its programming

16 EMC Documentum Content Server Version 6.5 Installation Guide

Single­repository model with content stored at primary

EMC Documentum Content Server Version 6.5 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 Installation Guide

The Distributed Configuration Guide provides details about this model.

Multirepository distributed model by using object

EMC Documentum Content Server Version 6.5 Installation Guide 19

Figure 6. Object replication model

The Distributed Configuration Guide provides details about this model.

Multirepository distributed model working as a

20 EMC Documentum Content Server Version 6.5 Installation Guide

Figure 7. Federation model

The Distributed Configuration Guide provides details about this model.

EMC Documentum Content Server Version 6.5 Installation Guide 21

Location for installing the relational database

Username Content Server will use to connect to the

22 EMC Documentum Content Server Version 6.5 Installation Guide

Size of repository to create

Chapter 9 Installing Remote ContentFile Servers in Distributed

Singlerepository model with content stored at primary

Singlerepository distributed model with content in a