Documentum 26.2 PostgreSQL 18 on Rocky Linux 9.6 (WSL2) Install Guide

Alvaro de AndresLeave a comment

This is a step-by-step guide to install Documentum 26.2 in WSL2 using the Rocky Linux 9 image with PostgreSQL 18. This version comes with some changes:

  • OT has rebranded (yet again) the products:
    • D2 -> classic
    • D2-Config -> config
    • D2-Smartview -> smartview
    • D2-Rest -> client-rest
  • Not happy with this, they have also renamed D2FS.properties to client.properties
  • And to increase the number of changes, all the log files have been renamed to match the new product names (However, totally unexpected from the “talented team”, they still are hardcoding the log path on Linux to “C:/Logs”. Maybe some day they’ll discover about catalina_home).
  • And talking about tomcat’s variables, Tomcat is the only supported application server.
  • Other features include:
    • Improvements and new features for Smartview, integration with M365 and the Guidewire integration
  • No word yet about Documentum Search but xPlore is back to be part of the official downloads
  • Remember this is part of the new support model for Documentum releases, where x.2 are considered “beta” versions for brave customers with shorter support, and x.4… are the same but with longer support.

Initial Configuration

There’s no official image on Microsoft Store so you’ll need to download the container image from the Rocky Linux page. Once this is done, you can import the image:

wsl --import RockyLinux9Dctm262 c:\Users\aldago\rockylinux262\ d:\dctm\dctm262\Rocky-9-Container-Base.latest.x86_64.tar.xz

After importing the image, we can log in (as root) and start the basic configuration of the server:

[root@desktop ~]# yum -y update
[root@desktop ~]# yum -y install sudo procps tcl expect libXtst xterm libxcrypt-compat

[root@desktop ~]# adduser dmadmin
[root@desktop ~]# passwd dmadmin
Changing password for user dmadmin.
New password:
BAD PASSWORD: The password is shorter than 8 characters
Retype new password:
passwd: all authentication tokens updated successfully.

[root@desktop ~]# usermod -aG wheel dmadmin
[root@desktop ~]# su - dmadmin
[dmadmin@aldago-desktop ~]$ sudo vi /etc/wsl.conf
[boot]
systemd=true

PostgreSQL Configuration

First we need to install PostgreSQL:

[root@desktop ~]# dnf install -y https://download.postgresql.org/pub/repos/yum/reporpms/EL-9-x86_64/pgdg-redhat-repo-latest.noarch.rpm
[root@desktop ~]# dnf -qy module disable PostgreSQL

[root@desktop ~]# dnf install -y postgresql18-server

[root@desktop ~]# /usr/pgsql-18/bin/postgresql-18-setup initdb
Initializing database ... OK

[root@desktop ~]# systemctl start postgresql-18
[root@desktop ~]# systemctl enable postgresql-18
Created symlink /etc/systemd/system/multi-user.target.wants/postgresql-18.service → /usr/lib/systemd/system/postgresql-18.service.
[root@desktop ~]# systemctl status postgresql-18

[root@desktop ~]# su - dmadmin
[dmadmin@desktop ~]$ sudo su - postgres
[sudo] password for dmadmin:
[postgres@desktop ~]$ psql
psql (18.4)
Type "help" for help.

postgres=# \password postgres
Enter new password for user "postgres":
Enter it again:
postgres=# exit
[postgres@desktop ~]$ exit
logout

[dmadmin@desktop ~]$ sudo passwd postgres
Changing password for user postgres.
New password:
BAD PASSWORD: The password is shorter than 8 characters
Retype new password:
passwd: all authentication tokens updated successfully.

Next, we can install phpgadmin for easier administration:

[root@desktop ~]# rpm -i https://ftp.postgresql.org/pub/pgadmin/pgadmin4/yum/pgadmin4-redhat-repo-2-1.noarch.rpm
[root@desktop ~]# dnf makecache.
[root@desktop ~]# dnf install -y pgadmin4-web                                                                            

[root@desktop ~]# /usr/pgadmin4/bin/setup-web.sh
Setting up pgAdmin 4 in web mode on a Redhat based platform...
Creating configuration database...
NOTE: Configuring authentication for SERVER mode.
Enter the email address and password to use for the initial pgAdmin user account:
Email address: dmadmin@dmadmin.dmadmin
Password:
Retype password:
You can now start using pgAdmin 4 in web mode at http://127.0.0.1/pgadmin4

And finally, we can configure the odbc connection:

[root@desktop ~]# yum -y install postgresql18-odbc.x86_64 unixODBC.x86_64
[root@desktop ~]# vi /etc/odbc.ini
[MyPostgres]
Description=PostgreSQL
Driver=PostgreSQL
Database=postgres                                                                                                       
Servername=localhost
UserName=postgres
Password=dmadmin
Port=5432                                                                                                               
Protocol=18
ReadOnly=No
RowVersioning=No
ShowSystemTables=No
ShowOidColumn=No                                                                                                        
FakeOidIndex=No
UpdateableCursors=Yes
DEBUG=Yes

[root@desktop ~]# vi /etc/odbcinst.ini
[PostgreSQL]
Description     = ODBC for PostgreSQL
Driver          = /usr/pgsql-18/lib/psqlodbcw.so
Driver64        = /usr/pgsql-18/lib/psqlodbcw.so
Setup64         = /usr/lib64/libodbcpsqlS.so.2
FileUsage       = 1

[root@desktop ~]# su - dmadmin
[dmadmin@desktop ~]$ isql -v MyPostgres
+---------------------------------------+
| Connected!                            |
|                                       |
| sql-statement                         |
| help [tablename]                      |
| echo [string]                         |
| quit                                  |
|                                       |
+---------------------------------------+
SQL>

Documentum Server

First, we need to create the DB folder:

[dmadmin@desktop ~]$ su - postgres
Password:
[postgres@desktop ~]$ mkdir /var/lib/pgsql/18/data/db_dctm262_dat.dat

The Documentum folders and JDK (stick to the supported 21 version and remember to remove anon from the disabled algorithms to avoid issues):

[dmadmin@desktop ~]$ sudo mkdir -p /opt/documentum/sw && sudo mkdir -p /opt/documentum/product/26.2
[dmadmin@desktop ~]$ sudo chown -R dmadmin:dmadmin /opt/documentum

Add environment variables to .bash_profile:

[dmadmin documentum]$ vi ~/.bash_profile
DOCUMENTUM=/opt/documentum
export DOCUMENTUM

DM_HOME=$DOCUMENTUM/product/26.2
export DM_HOME

DM_JMS_HOME=$DOCUMENTUM/tomcat
export DM_JMS_HOME

POSTGRESQL_HOME=/usr/pgsql-18
export POSTGRESQL_HOME

JAVA_HOME=/opt/documentum/jdk-21.0.9+10
export JAVA_HOME

PATH=$PATH:$DM_HOME/bin:$POSTGRESQL_HOME/bin:$HOME/.local/bin:$HOME/bin:$JAVA_HOME/bin:$DOCUMENTUM/dba
export PATH

LC_ALL=C
export LC_ALL

LD_LIBRARY_PATH=$POSTGRESQL_HOME/lib:$DM_HOME/bin:/usr/lib64:$LD_LIBRARY_PATH
export LD_LIBRARY_PATH

export DM_CRYPTO_MIN_PASSWORD_LENGTH=8

DISPLAY=:0
export DISPLAY

export PS1='[\u@\h \w]\$ '

Reserve ports and configure limits.conf:

[dmadmin ~]$ sudo vi /etc/services
dctm262 50000/tcp # dctm 26.2 repo
dctm262_s 50001/tcp # dctm 26.2 repo

[dmadmin ~]$ sudo vi /etc/security/limits.conf
dmadmin – core -1

[dmadmin@desktop /opt/documentum]$ sudo ln -s /usr/lib64/libsasl2.so.3.0.0 /usr/lib64/libsasl2.so.2
[dmadmin@desktop /opt/documentum]$ sudo ln -s /usr/lib64/libssl.so.3 /usr/lib64/libssl.so.10

And now you can simply install content server normally 🙂

RAG integration with Documentum without Aviator

Alvaro de AndresLeave a comment

Currently everyone wants to do “things” with AI, and content management is no different. Currently OpenText offers Aviator, which might be nice on the cloud (you can even try it for free), but is seems that if you are forced to run this locally (regulated content) you might have some issues, as it seems OpenText doesn’t have enough milking customers with X(pensive)-Plans, that you also have to pay (even more) for Aviator (at least, starting on 25.4, Aviator is available on premises).

Given the reputation of OpenText / Documentum in recent years in terms of support (we all love these cases opened for months to fix one line of code), quality of products (has anyone got SharePoint connector to work?) and their proven record on testing new products (Documentum Search…), it seems slightly optimistic to expect customers to pay (a lot) for something that nobody can guarantee how long it will take until you can effectively use it, or if it even will work at all.

So with this situation, best approach is to take on our hands how to do this. Basically, what we need to do is to apply our own RAG (Retrieval-augmented generation) solution to the documents stored in Documentum. For those of us that have not much idea about AI, this basically means we have to:

  • Vectorize documents
  • Ask question
  • Retrieve vectors
  • Send vectors to LLM
  • Get answer from LLM infered from the vectorized chunks

In order to do this we need a vector-compatible database (PostgreSQL works) and a LLM (Ollama running locally works). For this I’ll use my existing Documentum 23.4 environment.

First thing we need to do is to enable the vector extensión on PostgreSQL:

CREATE EXTENSION vector;

And we create a table in the Documentum schema:

CREATE TABLE dctm_rag_chunks (
    id UUID PRIMARY KEY,
    r_object_id VARCHAR(32),
    object_name VARCHAR(255),
    chunk_number INTEGER,
    content TEXT,
    embedding VECTOR(384)
);

with this, we need to create a few Java classes to do stuff. First, we will create a class to vectorize documents. This class is going to retrieve documents via REST, and will use something like Apache Tika to extract content from the files in form of chunks, and then store it in the database.

Once we have this, we can see something like this on the vectorized table:

At this point, we can test the retrieval of information, by querying this table, which will return results to our queries, but not in a “human readable” format:

what are the new features in documentum 25.4?

====================================================
RESULT #1
Document : Documentum Content Management Release Notes 25.4.pdf
Folder   : /Temp
ACL      : dm_4500271180000101
Owner    : dmadmin
Score    : 0.6950

or documentation updates that may have been posted after the initial release of this product. 1.1 Release Notes revision history Revision date Sections revised Description of revisions November 2025 First release. All new content. 2 About OpenText Documentum CM 25.4 This section provides an overview of OpenText Documentum CM CE 25.4. OpenText™ Documentum™ Content Management helps organizations pro...

====================================================
RESULT #2
Document : Documentum Content Management Release Notes 25.4.pdf
Folder   : /Temp
ACL      : dm_4500271180000101
Owner    : dmadmin
Score    : 0.6448

erience: Contains all Documentum Client components. • Compliance: Includes all certified records components. • RunStack Scale-Ups: Contains specialized components like Audio/Video Content Transformation Services and Branch Office Caching Services (BOCS). • Other Packages: APIs and Dev Tools, Advanced Workflow, Governance, Transformation Services, Microsoft Integrations, SAP Integrations, Cloud Uti...Then we can code an Ollama client, where we must retrieve the results from the vectorized table, and provide these, with a prompt, to the LLM model, which at the end is going to provide an answer such as:

This means our code is working so far. Now we need to connect this to a running AI model. For this we can install Ollama and run the llama3 model:

curl -fsSL https://ollama.com/install.sh | sh
ollama run llama3

Then we can code an Ollama client, where we must retrieve the results from the vectorized table, and provide these, with a prompt, to the LLM model, which at the end is going to provide an answer such as:

================================================
QUESTION: what are the new features in documentum 25.4?
================================================

================================================
ANSWER
================================================

According to the provided documents, specifically DOCUMENT: Documentum Content Management Release Notes 25.4.pdf, OBJECT ID: 0900271180004582, ACL: dm_4500271180000101, OWNER: dmadmin, FOLDER: /Temp, the new features in OpenText Documentum CM 25.4 are:

* Business Workspaces (3.2)
* Important new packaging for software downloads (3.1)
* Smart View: Business Workspaces (3.2.1)
* Smart View: Relationship Enhancements (3.2.2)
* Smart View: Added ability to “Select all” in a list and combo-box controls (3.2.3)
* Smart View: Document Location Enhancement (3.2.4)
* Smart View: Integration support with DocuSign (3.2.5)
* Smart View: Primary button label changes enhancement (3.2.6)
* Smart View: Streamlined Document Creation and Import (3.2.7)
* Full folder structure searches for Content Aviator (3.2.8)
* Virtual document searches for Content Aviator (3.2.9)
* On-Premises Content Aviator support for Documentum (3.2.10)

These features are described in sections 3 and 4 of the release notes.

================================================
SOURCES
================================================

Document : Documentum Content Management Release Notes 25.4.pdf
Object ID: 0900271180004582
ACL      : dm_4500271180000101
Owner    : dmadmin
Folder   : /Temp
Similarity: 0.6950

Besides this, as you can see in the examples, you can also add some metadata that can be useful:

  • ACLs: required for handling security / permissions
  • Folder path: required if you want to restrict the LLM to files in a specific folder

and whatever you want to add based on your requirements.

From this point, you can improve the vectorization process, use a better LLM, etc. to get the results you want. Finally, implementing a UI for D2/Smartview, you can have a similar “chat-like” AI assistant to what Aviator offers, for a much lower cost (but probably, hopefully, not as polished as Aviator).

Moving Documentum OTDSAuthenticator outside JMS

Alvaro de AndresLeave a comment

One of the new features from Documentum 25.4 is that OTDSAuthenticator runs now outside JMS. This brings a clear advantage: authentication doesn’t depend on JMS.

However, this is something we can easily achieve on earlier versions of Documentum and get some benefits as well:

  • As mentioned before, if JMS crashes or runs out of memory or whatever, your users will still be able to authenticate
  • If you’re running a cluster, you can use a DNS load balancer and actually have a balanced OTDSAuthenticator service (as how it works now is defining OTDSAuthenticator url as “localhost” which binds each node to its local OTDSAuthenticator, but this is not fault-tolerant, as losing one JMS will render that node useless as it won’t be able to authenticate users)

This process is actually quite simple:

  • Get an application server (Tomcat, Jetty, etc.)
  • Drop it on whatever folder on the server (I would use $DOCUMENTUM/otdsauth)
  • Modify the app server configuration to use an unused port instead of the default 8080
  • Copy $DM_JMS_HOME/webapps/OTDSAuthenticator to your app server webapps’ folder and start the server
  • Update dm_server_config entry for OTDSAuthenticator with your app server value (ie: http://localhost:8880/OTDSAuthentication/servlet/authenticate)
  • Reinit / restart repository

And that’s all, you’ll be using a standalone OTDSAuthenticator not dependant on JMS.

OpenText Intelligent Viewing 25.4 Linux install guide

Alvaro de AndresLeave a comment

This is a step-by-step guide to install Intelligent Viewing 25.4 in WSL2 using the Rocky Linux 9 image with PostgreSQL 17.

As a requisite, you’ll need to have a valid license for it, otherwise services will fail to properly start.

First step is to prepare the database, as I’m using the same VM used for Documentum 25.4 PostgreSQL 17 on Rocky Linux 9.6 (WSL2) Install Guide, you can create an additional “iv” user/database following the steps detailed on OTDS 24.4 on Rocky Linux 9.5 (WSL2) Install Guide. Just be aware that you need to create the “pgcrypto” extension.

Once the database is installed, we can start installing the first required applications and required packages such as nodeJS, npm, etc (Java is already present from Documentum Content Server installation)

[root@localhost ~]# yum -y install nodejs npm mesa-libGL mesa-libGLU Xvfb logrotate

[root@localhost ~]# node -v
[root@localhost ~]# npm -v

Once we’ve checked node and npm are installed and working, we have to install RabbitMQ, and for that we need to install the erlang dependency:

[root@localhost ~]# vi /etc/yum.repos.d/rabbitmq.repo
# In /etc/yum.repos.d/rabbitmq.repo

##
## Zero dependency Erlang RPM
##

[modern-erlang]
name=modern-erlang-el9
# Use a set of mirrors maintained by the RabbitMQ core team.
# The mirrors have significantly higher bandwidth quotas.
baseurl=https://yum1.rabbitmq.com/erlang/el/9/$basearch
        https://yum2.rabbitmq.com/erlang/el/9/$basearch
repo_gpgcheck=1
enabled=1
gpgkey=https://github.com/rabbitmq/signing-keys/releases/download/3.0/cloudsmith.rabbitmq-erlang.E495BB49CC4BBE5B.key
gpgcheck=1
sslverify=1
sslcacert=/etc/pki/tls/certs/ca-bundle.crt
metadata_expire=300
pkg_gpgcheck=1
autorefresh=1
type=rpm-md

[modern-erlang-noarch]
name=modern-erlang-el9-noarch
# Use a set of mirrors maintained by the RabbitMQ core team.
# The mirrors have significantly higher bandwidth quotas.
baseurl=https://yum1.rabbitmq.com/erlang/el/9/noarch
        https://yum2.rabbitmq.com/erlang/el/9/noarch
repo_gpgcheck=1
enabled=1
gpgkey=https://github.com/rabbitmq/signing-keys/releases/download/3.0/cloudsmith.rabbitmq-erlang.E495BB49CC4BBE5B.key
       https://github.com/rabbitmq/signing-keys/releases/download/3.0/rabbitmq-release-signing-key.asc
gpgcheck=1
sslverify=1
sslcacert=/etc/pki/tls/certs/ca-bundle.crt
metadata_expire=300
pkg_gpgcheck=1
autorefresh=1
type=rpm-md


##
## RabbitMQ Server
##

[rabbitmq-el9]
name=rabbitmq-el9
baseurl=https://yum2.rabbitmq.com/rabbitmq/el/9/$basearch
        https://yum1.rabbitmq.com/rabbitmq/el/9/$basearch
repo_gpgcheck=1
enabled=1
# Cloudsmith's repository key and RabbitMQ package signing key
gpgkey=https://github.com/rabbitmq/signing-keys/releases/download/3.0/cloudsmith.rabbitmq-server.9F4587F226208342.key
       https://github.com/rabbitmq/signing-keys/releases/download/3.0/rabbitmq-release-signing-key.asc
gpgcheck=1
sslverify=1
sslcacert=/etc/pki/tls/certs/ca-bundle.crt
metadata_expire=300
pkg_gpgcheck=1
autorefresh=1
type=rpm-md

[rabbitmq-el9-noarch]
name=rabbitmq-el9-noarch
baseurl=https://yum2.rabbitmq.com/rabbitmq/el/9/noarch
        https://yum1.rabbitmq.com/rabbitmq/el/9/noarch
repo_gpgcheck=1
enabled=1
# Cloudsmith's repository key and RabbitMQ package signing key
gpgkey=https://github.com/rabbitmq/signing-keys/releases/download/3.0/cloudsmith.rabbitmq-server.9F4587F226208342.key
       https://github.com/rabbitmq/signing-keys/releases/download/3.0/rabbitmq-release-signing-key.asc
gpgcheck=1
sslverify=1
sslcacert=/etc/pki/tls/certs/ca-bundle.crt
metadata_expire=300
pkg_gpgcheck=1
autorefresh=1
type=rpm-md

Now we can install the dependency:

[root@localhost ~]# dnf update -y
[root@localhost ~]# dnf install erlang -y

And install RabbitMQ:

[root@localhost ~]# wget https://github.com/rabbitmq/rabbitmq-server/releases/download/v4.2.2/rabbitmq-server-4.2.2-1.el8.noarch.rpm
[root@localhost ~]# rpm --import https://www.rabbitmq.com/rabbitmq-release-signing-key.asc
[root@localhost ~]# dnf install https://github.com/rabbitmq/erlang-rpm/releases/download/3.0/rabbitmq-erlang-26.2-1.el9.noarch.rpm -y

Now configure RabbitMQ:

[root@localhost ~]# rabbitmq-plugins enable rabbitmq_management
Enabling plugins on node rabbit@localhost:
rabbitmq_management
The following plugins have been configured:
rabbitmq_management
rabbitmq_management_agent
rabbitmq_web_dispatch
Applying plugin configuration to rabbit@localhost…
The following plugins have been enabled:
rabbitmq_management
rabbitmq_management_agent
rabbitmq_web_dispatch

started 3 plugins.

[root@localhost ~]# rabbitmqctl add_user mqadmin admin
[root@localhost ~]# rabbitmqctl set_user_tags mqadmin administrator
[root@localhost ~]# rabbitmqctl set_permissions -p / mqadmin ".*" ".*" ".*"

[root@localhost ~]# systemctl enable rabbitmq-server
Created symlink /etc/systemd/system/multi-user.target.wants/rabbitmq-server.service → /usr/lib/systemd/system/rabbitmq-server.service.
[root@localhost ~]# systemctl start rabbitmq-server

Now, you should be able to login into RabbitMQ’s console from http://localhost:15672 with the user just created:

Now, you need to copy the OT IV license replacing the existing INTELLIGENT_VIEWING.lic file on the installer folder. Once you have the license, you can run the OTDSConfig program that will upload the license and create the required configuration on OTDS:

[dmadmin@localhost /opt/documentum/sw/iv]$ ./OTDSConfig -u http://localhost:8180/otdsws -a <otds admin user> -p <otds admin password>

This will generate a _default_Auth.properties file with the following info:

LICENSE_RESOURCE=<value>
PUBLICATION_AUTH_CLIENT_ID=iv-publication
PUBLICATION_AUTH_CLIENT_SECRET=<value>
PUBLISHER_AUTH_CLIENT_ID=iv-publisher
PUBLISHER_AUTH_CLIENT_SECRET=<value>
SEARCH_AUTH_CLIENT_ID=iv-search
SEARCH_AUTH_CLIENT_SECRET=<value>

Take note of the values generated for the client ids as well as the value for the license resource. Now we have to edit the IntelligentViewing_Linux.properties file. Important values to modify here are the following:

ALLOW_DEFERRED_CONFIGURATION=false
JAVA_HOME=/opt/documentum/jdk-21.0.9+10
DEFAULT_HOST=localhost
OTDS_ORIGIN=http://localhost:8180/otdsws
OTDS_AUTH_FILE_PATH=/opt/documentum/sw/iv/_default_Auth.properties

LICENSE_RESOURCE=<value>
OT_INTEGRATION=true

DEFAULT_DB_HOST=localhost
DEFAULT_DB_PORT=5432
DEFAULT_DB_NAME=iv
DEFAULT_DB_USER=iv
DEFAULT_DB_PWD=<password>
DEFAULT_DB_USE_SSL=false
DEFAULT_DB_PROVIDER=postgresql

RMQ_HOST=localhost
RMQ_PORT=5672
RMQ_USER=mqadmin
RMQ_PWD=admin

PUBLISHER_AUTH_CLIENT_ID=iv-publisher
PUBLISHER_AUTH_CLIENT_SECRET=<value>
PUBLICATION_AUTH_CLIENT_ID=iv-publication
PUBLICATION_AUTH_CLIENT_SECRET=<value>
SEARCH_AUTH_CLIENT_ID=iv-search
SEARCH_AUTH_CLIENT_SECRET=<value>

Everything else should be ok with the existing values, so now we just have to run the intaller:

[root@localhost ~]# subscription-manager repos --enable rhel-7-server-optional-rpms

[root@localhost ~]# ./IV.Installer --install ./rpm --prereqs --configure ./IntelligentViewing_Linux.properties -l ./log.txt

[root@localhost ~]# chown -R otiv:otiv /home/otiv/.opentext

Hopefully the installer will finish correctly and IV will be installed. Logs can be checked on /var/log/opentext but we can also use the console application to check the status/adjust configuration:

[root@localhost ~]# /opt/opentext/ConfigurationTool/config-tool.sh

Now, we should try checking if this works or not. In the past, IV included a demo application (metis) but that is no longer the case. However, there’s a publicly available sample application on github: https://github.com/opentext/ivsa

Download the code, and create a .env file on the root of the project with the following values:

OTDS_ORIGIN=http://localhost:8180
OAUTH_CLIENT=test-iv
PUBLICATION_AUTHORITY=http://localhost:3356
MARKUP_AUTHORITY=http://localhost:3352
HIGHLIGHT_AUTHORITY=http://localhost:3357
VIEWER_AUTHORITY=http://localhost:3358
FILESTORE_PLUGIN=httpurl

This configuration will allow to test a file provided by url. For doing this I just copied the sample documents provided with this application to one of the tomcat’s ROOT webapp, so it can be accessed via browser.

Now we need to create an OTDS Oauth client named “test-iv” and add the following values to permisible scopes and default scopes:

view_publications
create_publications

Now we can build the application:

npm install
npm run build

As usual, the scripts are windows encoded, so before running the ivsa command make sure to run the dos2unix command on all files on the project, otherwise it won’t run. Finally, try to execute the ivsa application on one of the copied files to tomcat providing and user/pass existing in OTDS allocated to the IV license:

./ivsa -u <user> -p <pass> -V http://localhost:8180/wilhome.dwg

And you should see this:

Documentum 25.4 PostgreSQL 17 on Rocky Linux 9.6 (WSL2) Install Guide

Alvaro de Andres3 Comments

This is a step-by-step guide to install Documentum 25.4 in WSL2 using the Rocky Linux 9 (closest to the supported RH9) image with PostgreSQL 17. This version comes with some changes:

  • OT has repackaged (and rebranded for the 100000th time again the products) the installer into zip files
    • Documentum CM runstack:
      • Content Server PostgreSQL and Oracle
      • Documentum Administrator
      • Process Engine
      • Workflow Designer
      • Thumbnail Server
      • iJMS
    • Documentum CM experience:
      • Documentum Clients
        • D2 (now called “Classic”) and SDK
        • D2-Config
        • D2-Smartview and SDK
        • Administration Console
        • D2-REST and SDK
        • D2 Mobile
        • D2 Plugins (C2, O2, etc.)
    • Documentum CM API and Dev tools:
      • Composer
      • DFC
      • DFS and SDK
      • DCTM-REST and SDK
      • CMIS
      • Connector for Core
  • Documentum Search is no longer available (until at least 2027) because of performance and result inconsistency issues
  • Tomcat supported version is now 11 (will OT ever update xPlore’s Tomcat?)
  • JMS tomcat no longer has the version on the folder path (now is $DOCUMENTUM/tomcat)
  • OTDSAuthenticator is no longer part of the JMS, but it runs as an http service listening on port 8400. The binaries/configuration are located on $DM_HOME/OTDSAuthLicenseHttpServerBin and the otdsauth.log is now located on $DOCUMENTUM/dba/log
  • We have the new admin console which in theory should replace (one of this years :D) DA. As we have seen for many years with D2, everything comes “preconfigured” for windows (dfc.properties points to “C:\Documentum\config\dfc.properties” on Linux packages). In a “default” installation you can skip deploying this as it has no use:
  • Clients (D2) now have a similar installer as the CS, but OT still can’t properly configure log paths (Engineering must have never heard of catalina.base/home variables. Will they ever stop making all log files on Linux point to C:\Logs\xxx.log?)

Initial Configuration

I will not go through the basic configuration, as you can follow the steps detailed for Documentum 25.2. You just need to use proper Java version and modify the environment variables that change ($DM_HOME, $DM_JMS_HOME, $JAVA_HOME).

Also remember to start the OTDS authentication HTTP service if you want to use licenses, otherwise you could only login into DA. In case you want to setup licensing you can follow the steps from theOTDS licensing configuration post.

Client installation

You’ll need to unzip the clients package zip and run ./Documentum-Client-Installer.bin:

It looks like we finally have support for multiple repositories configuration:

After the installation is done you’ll have the war files ready to be deployed:

  • Drop the files to your Tomcat 11 installation
  • Update dfc.properties and log4j2 and logback configuration (as everything will be writing to C:\xxx)
  • Register dfc.keystores as approved clients

Documentum xPlore vs. Tomcat 10

Alvaro de Andres1 Comment

If you are registered on the OpenText site you’ve probably received this week the notification about the status of xPlore:

  • xPlore 22.1 will be the last version of xPlore, with Patch 12 being the supported version
  • Documentum search is now officially listed as the replacement of xPlore
  • Support for xPlore will finish on 2027 (+ extended)

If you have checked “recently” xPlore 22.1 patches, you’ll have realized that OpenText moved from Wildfly to Tomcat 9 during these patches (on Patch 04 or 05, if I remember correctly) as well as moving to JDK 17. However, despite P12 supporting JDK 21, xPlore still uses Tomcat 9 (remember that latest branch is Tomcat 11, with Tomcat 10 being the version considered “standard” as of today). This situation is strange because all the Documentum stack is running in Tomcat 10… except this. And despite having KBs on how to upgrade Tomcat with minor versions (KB0833958 and KB0833423) is still weird that this is not done yet.

It happens that I had opened a case just a few days before getting the notification mail asking about the status of xPlore and Tomcat 10 (due to Tomcat 9 vulnerability topics) and got this answer: 

"Moving to Tomcat 10.x would need upgrading code compilation to Java17. 
This is a larger effort which is not planned."

So… not believing this statement (as we have recently upgraded everything to Java 17 and it has been basically replacing javax.* packages with jakarta.* packages, and it hasn’t been that much of a “larger effort”) for 3 web applications (dsearch, dsearchadmin and indexagent) I decided to check how difficult this would really be.

First thing, I had to install locally xPlore 22.1, then upgrade it to 22.1 P12 and finally create the PrimaryDsearch and IndexAgent instances. So far, so good.

So let’s try this:

  • Download latest Tomcat 10.1 (currently 10.1.47)
  • Unpack twice the Tomcat 10.1 package (PrimaryDsearch_tomcat10.1.47 and Indexagent_tomcat10.1.47)
  • For PrimaryDsearch instance:
    • Copy PrimaryDsearch_tomcat9.0.100/admindata
    • Copy PrimaryDsearch_tomcat9.0.100/dctmInfo.properties
    • Copy PrimaryDsearch_tomcat9.0.100/webapps (dsearch and dsearchadmin)
    • Copy PrimaryDsearch_tomcat9.0.100/bin scripts (start/stopPrimarySearch and dctmServerStatus.sh)
    • Update PrimaryDsearch_tomcat10.1.47/admindata/admindb/XhiveDatabase.bootstrap with Tomcat 10 path
    • Update PrimaryDsearch_tomcat10.1.47/conf/server.xml to use port 9300
    • Update copied scripts to bin folder with Tomcat 10.1 path
    • Update loggging configuration with Tomcat 10.1 path
  • For IndexAgent instance:
    • Copy Indexagent_tomcat9.0.100/dctmInfo.properties
    • Copy Indexagent_tomcat9.0.100/webapps (IndexAgent)
    • Copy Indexagent_tomcat9.0.100/bin scripts (start/stopPrimarySearch and dctmServerStatus.sh)
    • Update Indexagent_tomcat10.1.47/webapps/IndexAgent/WEB-INF/classes/indexagent.xml with Tomcat 10.1 path
    • Update Indexagent_tomcat10.1.47/conf/server.xml to use port 9200
    • Update copied scripts to bin folder with Tomcat 10.1 path
    • Update loggging configuration with Tomcat 10.1 path

Then we start both Tomcat 10 and… nothing 😀 As expected the javax.* references make this unable to work with Tomcat 10. So what can we do? “Normal” approach would be taking the original source code and replacing javax.* with jakarta.* and dependenies on libraries but a) I do not have the original source code and b) I do not want to be decompiling all the jars. So it is really a large effort? I do not think so.

Apache provides a migration tool that can modify all the references to javax in all the files of your application. So… what if we give it a try? We just need to download the tool and execute it:

./migrate.sh /opt/xplore/PrimaryDsearch_tomcat10.1.47/webapps/javax_dsearch /opt/xplore/PrimaryDsearch_tomcat10.1.47/webapps/dsearch
./migrate.sh /opt/xplore/PrimaryDsearch_tomcat10.1.47/webapps/javax_dsearchadmin /opt/xplore/PrimaryDsearch_tomcat10.1.47/webapps/dsearchadmin
./migrate.sh /opt/xplore/IndexAgent_tomcat10.1.47/webapps/javax_IndexAgent /opt/xplore/IndexAgent_tomcat10.1.47/webapps/IndexAgent

And after few seconds the tool will finish converting the applications and we just have to delete the javax_xxx folders and start PrimaryDsearch and IndexAgent. And what happens now?

Dsearchadmin:

IndexAgent:

IndexAgent status from DA:

Search results:

Total time for this: ~20 min give or take. Considering that probably writing this post has taken me longer that this, not sure if we can qualify this as a “large effort” 😀

Documentum D2 LoadOnStartup performance improvements

Alvaro de AndresLeave a comment

If you’re using D2 (or Smartview) you probably have realized that the LoadOnStartup parameter which is required for certain features (ie: application list) also makes D2 startup slower.

Depending on the number of repositories/applications this startup time can be very long or extremely long (we’re talking about a web application). As an example, our servers take ~5-7 minutes to complete the startup of D2, but even “funnier” is the situation with our laptops, where (thanks to all the security AV, inventory tools and such) the same war file from dev/qs/prod can take ~20 minutes to start.

How is this possible? Well, I asked myself the same question when I accidentally had to check some code on some classes related to this topic. What I found was that what LoadOnStartup does is basically this:

  • Populates the type cache
  • Populates the labels for the types
  • Caches the configuration objects (so if you have a lot, this will take some “seconds”)
  • Populates the labels for every attribute and language (and this will take even minutes depending on how many languages/attributes you have, as it happens for everything, not discriminating even internal attributes not used)

You can see these in the following excerpt from D2.log in full debug mode:

Refresh cache for type : dm_document
Refresh cache for type : d2_pdfrender_config
...
Refresh format label cache
...
Refresh xml cache for object d2_portalmenu_config with object_name MenuContext
...
Refresh en attribute label cache
..

Is this really a problem? Well, not “by default”, but if you have 5-6 repositories with many types and many languages, this becomes… slow.

So, taking a look at the code, we saw that most of the time (or the most significant situation) was happening with the attribute label cache, which would stop for 30-40 seconds for each language. This code is located in com.emc.common.dctm.bundles.DfAbstractBundle.loadProperties method:

query.setDQL(dql);
col = query.execute(newSession, 0);

while(col.next()) {
	String name = col.getString("name");
	String label = col.getString("label");
        if (col.hasAttr("prefix")) {
		String prefix = col.getString("prefix");
                StringBuffer tmpName = new StringBuffer(prefix);
                tmpName.append('.');
                tmpName.append(name);
                name = tmpName.toString();
        }

This dql is “select type_name as name, label_text as label from dmi_dd_type_info where nls_key = ‘en’” which can return tens of thousands of results, and this is executed for each language configured in the repository. And this code is called from the com.emc.d2fs.dctm.servlets.init.LoadOnStartup class:

int count = docbaseConfig.getValueCount("dd_locales");
for (int i = 0; i < count; i++) {
      String strLocale = docbaseConfig.getRepeatingString("dd_locales", i);
      DfSessionUtil.setLocale(session, LocaleUtil.getLocale(strLocale));
      LOG.debug("Refresh {} type label cache", strLocale);
      DfTypeBundle.clearCache(session);
      DfTypeBundle.getBundle(session);
      LOG.debug("Refresh {} attribute label cache", strLocale);
      DfAttributeBundle.clearCache(session);
      DfAttributeBundle.getBundle(session);
}

The getBundle method is running at the end that query for the labels… So improvement possibilities? Clear one: multithreading. We modified this block of code to run with multiple threads (one per language), and what happened? We cut down the startup time by 2-3 minutes, fantastic, right? Yes 🙂 but then we thought: The log clearly shows that LoadOnStartup is a sequential process that repeats the same stuff for each repository… so could we run the “repository initialization” in parallel? Let’s see:

Iterator<IDfSession> iterator = (Iterator<IDfSession>)object;
        while (iterator.hasNext()) {
          IDfSession session = iterator.next();
          try {
            if (session != null) {
              refreshCache(session);
              if (cacheBocsUrl)
                loadBocsCache(session); 
            } 
          } finally {
            try {
              if (session != null)
                session.getSessionManager().release(session); 
            } catch (Exception exception) {}
          } 
        }

This block of code is what initiates the LoadOnStartup process for each repository with the “refreshCache” method. So what happens if we also add multithreading to this block of code? Well, that it works:

[pool-5-thread-2] - c.e.d.d.s.i.LoadOnStartup[   ] : Refresh cache for type : d2_subscription_config
[pool-5-thread-1] - c.e.d.d.s.i.LoadOnStartup[   ] : Refresh cache for type : d2_toolbar_config
[pool-5-thread-3] - c.e.d.d.s.i.LoadOnStartup[   ] : Refresh cache for type : d2_attribute_mapping_config
[pool-5-thread-2] - c.e.d.d.s.i.LoadOnStartup[   ] : Refresh cache for type : d2_sysobject_config

You can see how the type cache is populated in parallel by using a different thread for each repository. And what about times? Well, these are the times for the “normal” startup, parallel loading of labels, and parallel loading of the repository configuration and labels taken on my laptop:

[1271387] milliseconds
[1058355] milliseconds
[435735] milliseconds

So, original startup time without touching anything: 21 minutes. Multithreading the attribute label cache: 17 minutes. Full multithread: 7 minutes.

Don’t know, but maybe OT guys should take a look at this and consider a “performance improvement” patch for D2/Smartview…

Documentum 25.2 PostgreSQL 17 on Rocky Linux 9.6 (WSL2) Install Guide

Alvaro de Andres3 Comments

This is a step-by-step guide to install Documentum 25.2 in WSL2 using the Rocky Linux 9 (closest to the supported RH9) image with PostgreSQL 17. This versions comes with some changes:

  • Due to the deprecation of MS SMTP basic authentication, installer now allows using a M365/MSGraph account for setting mail:

Initial Configuration

There’s no official image on Microsoft Store so you’ll need to download the container image from the Rocky Linux page. Once this is done, you can import the image:

wsl --import RockyLinux9Dctm252 c:\Users\aldago\rockylinux252\ d:\dctm\dctm252\Rocky-9-Container-Base.latest.x86_64.tar.xz

After importing the image, we can log in (as root) and start the basic configuration of the server:

[root@desktop ~]# yum -y update
[root@desktop ~]# yum -y install sudo procps tcl expect libXtst xterm libxcrypt-compat

[root@desktop ~]# adduser dmadmin
[root@desktop ~]# passwd dmadmin
Changing password for user dmadmin.
New password:
BAD PASSWORD: The password is shorter than 8 characters
Retype new password:
passwd: all authentication tokens updated successfully.

[root@desktop ~]# usermod -aG wheel dmadmin
[root@desktop ~]# su - dmadmin
[dmadmin@aldago-desktop ~]$ sudo vi /etc/wsl.conf
[boot]
systemd=true

PostgreSQL Configuration

First we need to install PostgreSQL:

[root@desktop ~]# dnf install -y https://download.postgresql.org/pub/repos/yum/reporpms/EL-9-x86_64/pgdg-redhat-repo-latest.noarch.rpm
[root@desktop ~]# dnf -qy module disable PostgreSQL

[root@desktop ~]# dnf install -y postgresql17-server

[root@desktop ~]# /usr/pgsql-17/bin/postgresql-17-setup initdb
Initializing database ... OK

[root@desktop ~]# systemctl start postgresql-17
[root@desktop ~]# systemctl enable postgresql-17
Created symlink /etc/systemd/system/multi-user.target.wants/postgresql-17.service → /usr/lib/systemd/system/postgresql-17.service.
[root@desktop ~]# systemctl status postgresql-17

[root@desktop ~]# su - dmadmin
[dmadmin@desktop ~]$ sudo su - postgres
[sudo] password for dmadmin:
[postgres@desktop ~]$ psql
psql (17.5)
Type "help" for help.

postgres=# \password postgres
Enter new password for user "postgres":
Enter it again:
postgres=# exit
[postgres@desktop ~]$ exit
logout

[dmadmin@desktop ~]$ sudo passwd postgres
Changing password for user postgres.
New password:
BAD PASSWORD: The password is shorter than 8 characters
Retype new password:
passwd: all authentication tokens updated successfully.

Next, we can install phpgadmin for easier administration:

[root@desktop ~]# dnf -y install yum-utils
[root@desktop ~]# rpm -i https://ftp.postgresql.org/pub/pgadmin/pgadmin4/yum/pgadmin4-redhat-repo-2-1.noarch.rpm
warning: /var/tmp/rpm-tmp.CQz9dX: Header V4 RSA/SHA256 Signature, key ID 210976f2: NOKEY
[root@desktop ~]# yum-config-manager --disable pgdg-common
Error: No matching repo to modify: pgdg-common.
[root@desktop ~]# dnf update -y                                                                            
[root@desktop ~]# dnf install pgadmin4 -y

[root@desktop ~]# systemctl enable --now httpd
Created symlink /etc/systemd/system/multi-user.target.wants/httpd.service → /usr/lib/systemd/system/httpd.service.
[root@desktop ~]# systemctl status httpd

[root@desktop ~]# /usr/pgadmin4/bin/setup-web.sh
Setting up pgAdmin 4 in web mode on a Redhat based platform...
Creating configuration database...
NOTE: Configuring authentication for SERVER mode.
Enter the email address and password to use for the initial pgAdmin user account:
Email address: dmadmin@dmadmin.dmadmin
Password:
Retype password:
You can now start using pgAdmin 4 in web mode at http://127.0.0.1/pgadmin4

And finally, we can configure the odbc connection:

[root@desktop ~]# dnf install https://download.postgresql.org/pub/repos/yum/reporpms/EL-9-x86_64/pgdg-redhat-repo-latest.noarch.rpm
[root@desktop ~]# yum -y install postgresql17-odbc.x86_64 unixODBC.x86_64
[root@desktop ~]# vi /etc/odbc.ini
[MyPostgres]
Description=PostgreSQL
Driver=PostgreSQL
Database=postgres                                                                                                       
Servername=localhost
UserName=postgres
Password=dmadmin
Port=5432                                                                                                               
Protocol=17
ReadOnly=No
RowVersioning=No
ShowSystemTables=No
ShowOidColumn=No                                                                                                        
FakeOidIndex=No
UpdateableCursors=Yes
DEBUG=Yes

[root@desktop ~]# vi /etc/odbcinst.ini
[PostgreSQL]
Description     = ODBC for PostgreSQL
Driver          = /usr/pgsql-17/lib/psqlodbcw.so
Driver64        = /usr/pgsql-17/lib/psqlodbcw.so
Setup64         = /usr/lib64/libodbcpsqlS.so.2
FileUsage       = 1

[root@desktop ~]# su - dmadmin
[dmadmin@desktop ~]$ isql -v MyPostgres
+---------------------------------------+
| Connected!                            |
|                                       |
| sql-statement                         |
| help [tablename]                      |
| quit                                  |
|                                       |
+---------------------------------------+
SQL>

Documentum Server

First, we need to create the DB folder:

[dmadmin@desktop ~]$ su - postgres
Password:
[postgres@desktop ~]$ mkdir /var/lib/pgsql/17/data/db_dctm252_dat.dat

The Documentum folders and JDK (stick to the supported 21 version and remember to remove anon from the disabled algorithms to avoid issues):

[dmadmin@desktop ~]$ sudo mkdir -p /opt/documentum/sw && sudo mkdir -p /opt/documentum/product/25.2
[dmadmin@desktop ~]$ sudo chown -R dmadmin:dmadmin /opt/documentum

Add environment variables to .bash_profile:

[dmadmin documentum]$ vi ~/.bash_profile
DOCUMENTUM=/opt/documentum
export DOCUMENTUM

DM_HOME=$DOCUMENTUM/product/25.2
export DM_HOME

DM_JMS_HOME=$DOCUMENTUM/tomcat10.1.39
export DM_JMS_HOME

POSTGRESQL_HOME=/usr/pgsql-17
export POSTGRESQL_HOME

JAVA_HOME=/opt/documentum/jdk-21.0.5+11
export JAVA_HOME

PATH=$PATH:$DM_HOME/bin:$POSTGRESQL_HOME/bin:$HOME/.local/bin:$HOME/bin:$JAVA_HOME/bin:$DOCUMENTUM/dba
export PATH

LC_ALL=C
export LC_ALL

LD_LIBRARY_PATH=$POSTGRESQL_HOME/lib:$DM_HOME/bin:/usr/lib64:$LD_LIBRARY_PATH
export LD_LIBRARY_PATH

export DM_CRYPTO_MIN_PASSWORD_LENGTH=8

DISPLAY=:0
export DISPLAY

export PS1='[\u@\h \w]\$ '

Reserve ports and configure limits.conf:

[dmadmin ~]$ sudo vi /etc/services
dctm252 50000/tcp # dctm 25.2 repo
dctm252_s 50001/tcp # dctm 25.2 repo

[dmadmin ~]$ sudo vi /etc/security/limits.conf
dmadmin – core -1

[dmadmin@desktop /opt/documentum]$ sudo ln -s /usr/lib64/libsasl2.so.3.0.0 /usr/lib64/libsasl2.so.2
[dmadmin@desktop /opt/documentum]$ sudo ln -s /usr/lib64/libssl.so.3 /usr/lib64/libssl.so.10

And now you can simply install content server normally 🙂

Documentum 24.4 OTDS licensing configuration

Alvaro de Andres1 Comment

Starting with Documentum 24.4, OTDS is now mandatory for managing licenses, meaning that you won’t be able to use any client without license (not even with dmadmin). OpenText has a white paper on the support page called “OpenText™ Documentum 24.4 – OTDS Configuration” that you can check (as it has had several iterations with several updates).

This post will cover the minimal steps required to set-up a development environment (after you request a developing license), as these are… some steps (wonder how is this supposed to work on a cloud environment… you deploy your wonderful kubernetes cluster and… nothing works until you manually perform all these steps?).

Following the white paper, the first step is creating a new non-synchronized partition, that later will be populated with the repository inline users (I do not even want to ask what happens when you have more than one repository and these users have different passwords!):

After this, you can ignore the creation of the resource, as it is not required to create the users via OTDS (if you’re going to use dmadmin or a few users, you probably already have these on the repository and will be “imported” to OTDS, so the resource is not needed).

Then, you need to import the license provided by OT support.

Now that we’re done with the “prerequisites”, we need to create what OT calls “business admin user” which is basically the user DCTM will use to connect to OTDS and check the license. This user needs to be created first on OTDS and then added to the “otdsbusinessadmins” groups.

After this, we need to create the user again in Documentum. For this, the guide suggests to use the following API script:

create,c,dm_otds_license_config
set,c,l,otds_url
http://localhost:8180/otdsws/rest
set,c,l,license_keyname
dctm-xplan
set,c,l,business_admin_name
licenseuser
set,c,l,business_admin_password
<password>
save,c,l

Once this is created we need to allocate the existing license to an OTDS partition. With this step the “initial setup” is done and you should see something like this on DA:

Now we need to create the inline users (dmadmin) in the OTDS partition so these are “licensed” to use application. For some reason (lack of knowledge I guess), OT complicates things too much as, not only you have to run a command-line Java command, but the documentation forces you to create a copy of dfc.properties in the dfc folder (??!!??!!) and to explicitly declare the environment variables for Java… that should be already present on the system (otherwise Documentum won’t be working properly… which I could expect happens to the talented team :D).

So instead of following the instructions on the white paper, just run the following command:

java -Ddfc.properties.file=$DOCUMENTUM/config/dfc.properties -cp "$DOCUMENTUM/dfc/*" com.documentum.fc.tools.MigrateInlineUsersToOtds <repository> <install owner> <password> <non-sync Partition name>

which looks way better than this monster:

Finally (yes, we’re almost done), you need to update otdsauth.properties file under JMS with the proper information, restart everything and hopefully, you’ll have now a licensed development environment.

OTDS FAQ for Documentum

Alvaro de Andres1 Comment

If you work with Documentum, sooner or later you’ll have to face that moment were you’re going to have to use OTDS in your system (as this is mandatory since Documentum 23.4). I will try to provide some insights and tips about OTDS and Documentum in this post.

OTDS is basically an IDP (an authentication/access control system) that OpenText created (having in mind “other” solutions more limited than Documentum) and that they have been pushing to many of the products of their portfolio.

What are the positive things that OTDS brings to the table when we are talking about Documentum?

  • Centralized authentication management (as in: configure you authentication in 1 place, and reuse for all components, removing the need of having different libraries/configurations in webtop, d2, rest, etc.)
  • Centralized user/groups management: I just don’t buy this, because it relies on companies having a “perfectly organized LDAP/AD” which I’ve never ever seen. Even worse if we include here application-level group/roles, where in Documentum you can have group structures defined that are years away for any existing configuration in any AD/LDAP (and I do not see anyone manually creating thousand of existing Documentum groups in OTDS).
  • Centralized licensing management (another push from other products, we will see how this really works, as I already expressed my concerns in a previous post)

Obviously, not everything is fantastic, and the are several topics you should be aware of:

  • An authentication system is totally outside the scope of ECM departments, meaning that no ECM expert is capable of properly evaluating, configuring or maintaining a system of this kind (have a talk with your cybersecurity/authentication team before doing anything!). Not only that, this can conflict with existing policies in your company regarding authentication policies.
  • OTDS is not a product (check OT’s product page) but it is considered a “component” of other products. What does this mean?
    • You’re using a critical (as it is what it is supposed to handle access to your data) product which is not “recognized” even by their own vendor
    • OT has a leader solution in this field, NetIQ, which came with MicroFocus, so it is not clear what their roadmap is regarding IDPs.
    • There’s no “product support” for OTDS, but this is delegated to other product teams (ie: Documentum support). Obviously, they have no idea about OTDS itself, and OT bureaucracy makes highly complicated to get an answer when you have an issue.
  • OTDS is a single point of failure: OTDS doesn’t work -> No user can work, even if everything else is up and running.
  • OTDS was conceived for other, much simpler, OT’s products. As Documentum is kind of a Swiss army knife, OTDS greatly limits existing DCTM configurations (which makes this integration a challenge in certain environments)

So, given these topics, what scenarios can we found when integrating OTDS?. Well, it depends on your existing system. I think most systems can be grouped in three different categories:

  • Highly regulated / complex systems: You have your own IDP (EntraID, NetIQ, etc.), you also have your own system to handle access to Documentum (ie: automatic creation of users on repositories). This also includes multiple repositories in the organization, and many applications with many groups.
  • Small installations: Single repository approach, not many users, not many groups, still using user/password login
  • New systems / upgrades to a “clean” system

Based on this, what is the best (or only) approach to integrate OTDS in these scenarios?

  • Highly regulated / complex systems: Forget about documentation. You do not need resources, access roles or anything. Just use a synchronized partition with the required oauth clients and delegate authentication to your existing IDP. Minimal configuration, minimal maintenance (other than getting this to work). OTDS here acts just a proxy for getting the OTDS token that will be used by DCTM applications.
  • Small installations: Ideal scenario as you’re using Documentum as some of the other, more limited products from OT, so this is what OTDS was originally intended for. Probably you’ll only effort will be manually configuring groups.
  • New systems / upgrades: You “should” try to use OTDS in the “expected” way. Be aware of several limitations coming from the lack of support for existing solutions in Documentum:
    • Multirepository configurations are a nightmare. Nobody seem/wants to understand that you can have different users, in different repositories, and this can be a challenge.
    • Mix of functional/inline accounts and users accounts can be a challenge as well.

Finally, some tips that you should consider when using OTDS:

  • As soon as it is configured, add you organization users responsible for OTDS to the admin group, disable the otds.admin account and force 2FA authentication (and manually remove the user/pass login from otds-admin). You do not want to expose the admin page to anybody (even less if you have this running on a public cloud) as this is a huge security risk.
  • Token TTL is a topic when dealing with timeouts. Until now you only had to worry about web application timeout, but now also the OTDS token can expire, so the TTL should be something like TTL=timeout+buffer of time, so if a user stops using an application after 1 hour, and you have defined a 4 hours timeout on the application, your token needs to be valid for at least 5 hours.
  • When configuring D2, completely ignore the documentation. By no means mess with the tickets (who thought of this approach? who allowed this to be done??) or perform the configuration part that tells you to enable the “Global Registry encryption in other repositories”. This is no longer required since 23.4 P09 (you’re welcome) as it is a huge security risk (and I’m quoting the talented engineering team here: “a design flaw”, but they still seem to have forgotten to remove that section from documentation).
  • Make sure you test all scenarios before going live or you’ll be in trouble, as fixing these “live” will be challenging:
    • Web interface authentication
    • DFC interface authentication
    • Token authentication
    • OTDS token generation from external authenticator token
    • Any existing user configuration authentication (LDAP, inline, functional accounts, direct url access to components, etc.)