Quick answer
Most OpenText Documentum trouble lands in one of five buckets: D2 or Webtop is slow (Content Server sessions, the repository database, or the application server JVM), jobs never complete (agent exec, the Java Method Server, or one failing method), search is stale (the xPlore index agent), users get permission errors (ACLs and group membership), and clients cannot connect (the connection broker or the server config). Each has a first check that rules the common cause in or out in minutes. They are below, in order.
Documentum fails quietly. The Content Server process stays up, the application server answers, and the platform dashboard stays green while a lifecycle job has not run in nine days, the index is a week behind, and the D2 users have learned to click twice. This page is the triage order for those calls: the symptom, the first thing to check, and the fix.
The search bucket has its own full write-up — Documentum search not returning documents. (The full catalog of Documentum health checks and tests is published here, ungated.)
01 — The Symptoms
What is wrong with Documentum? Five symptoms and the first check for each
Match the call you just took, then jump to the fix.
| # | What users report | Most likely cause | First check |
|---|---|---|---|
| 1 | D2 or Webtop is slow; folder listings hang; downloads time out | Content Server at or near its concurrent session limit; a long-running query holding locks in the repository database; D2 application server JVM short of heap or threads | Active sessions on the Content Server against the concurrent_sessions setting |
| 2 | Lifecycle, retention, or cleanup jobs sit in Running or never start; the dmclean and dmfilescan jobs stopped weeks ago | Agent exec not running; the Java Method Server down or out of memory; one job inactive, failing in its method, or scheduled against a server that no longer exists | dm_job: last completion date and current status for the job in question |
| 3 | Search returns nothing for a document that opens fine from its folder; results are days old | The xPlore index agent is stalled or backlogged; individual items failed content extraction; the index is out of step after a migration | Index agent status and the pending and failed counts in the xPlore admin console |
| 4 | “You do not have sufficient permission”; a user sees a folder but not its documents; a new hire sees nothing | The object’s ACL does not grant the permit level; the user’s repository group membership is out of step with the directory; the LDAP sync job (symptom 2) has not run | The object’s ACL and the user’s groups, by DQL |
| 5 | Clients cannot connect at all: “docbroker not reachable,” DFC login errors, D2 shows no repositories | The connection broker is down or the Content Server failed to project to it; dfc.properties points at the wrong broker host or port; a certificate or firewall change | Ping the connection broker from the client machine with dmqdocbroker |
Symptom 2 is the one that hides the longest. Documentum jobs fail silently by design: a job that cannot run does not alert, and the business effects — retention not applied, orphaned content filling the file store, directory users not synchronized — arrive weeks later wearing a different symptom. The LDAP synchronization job not running is the usual root of symptom 4; the dmclean and dmfilescan jobs not running is the usual root of a full file store. Check the job table on every Documentum ticket, whatever the ticket says.
02 — The Fixes
How do you fix each Documentum problem? The repair sequence
In order within each symptom. Everything below runs from idql, iapi, Documentum Administrator, or the xPlore admin console.
-
Slowness: count sessions, then find the query, then size the JVM
From iapi, list what the Content Server is holding: execute show_sessions gives every session, its user, and its age; execute list_sessions gives the count. Compare it to concurrent_sessions in server.ini. A count at the limit with hundreds of idle sessions is a client leaking sessions, usually an integration or a custom DFC application that never disconnects; find it by user and fix the client before raising the limit. If sessions are fine, look at the repository database for blocking and long-running statements at the time of the complaint, and at the Content Server log ($DOCUMENTUM/dba/log/<repository>.log) for query timeouts. If both are clean, the application tier is the bottleneck: check the D2 or Webtop JVM for heap exhaustion and thread-pool saturation in its application server log, and size it to the concurrent user count.
-
Jobs: read the job table, then the job’s report, then the method server
Start with what has and has not run:
SELECT object_name, a_last_completion, a_current_status, run_interval, is_inactive, target_server FROM dm_job WHERE is_inactive = 0 ORDER BY a_last_completion;Every active job stuck at the same old date means the scheduler itself: confirm the agent exec process is running on the Content Server and that the Java Method Server is up and answering (http://<jms-host>:9080/DmMethods/servlet/DoMethod returns a response, and ServerApps.log is not full of out-of-memory errors). One job stuck means that job: open it in Documentum Administrator, read its report for the last error, check that target_server still names a live Content Server, and that is_inactive was not set by a previous failure. A job stuck in Running with no process behind it needs a_current_status cleared before the scheduler will pick it up again.
-
Search: check the index agent before you touch the index
Open the xPlore admin console and the index agent console. An agent in a stopped or error state explains a stale index outright: restart it and let it work the queue. A running agent with a growing pending count is behind, not broken; give it time or capacity. A rising failed count is content extraction failing on specific items; find them, fix the content or the Content Processing Service, and resubmit. A full reindex is for a corrupt index or a failed migration, not for lag. The complete sequence, with the queue and item queries, is in Documentum search not returning documents.
-
Permissions: read the ACL, then the groups, then the sync job
Find the object’s ACL and what it grants:
SELECT acl_name, acl_domain FROM dm_sysobject WHERE r_object_id = ‘<object id>’; SELECT r_accessor_name, r_accessor_permit, r_accessor_xpermit FROM dm_acl WHERE object_name = ‘<acl_name>’ AND owner_name = ‘<acl_domain>’; SELECT group_name FROM dm_group WHERE ANY users_names = ‘<user_name>’;Permit levels are numeric — 1 none, 2 browse, 3 read, 4 relate, 5 version, 6 write, 7 delete — and the user gets the highest level granted to them or to any group they are in. A user missing from every granted group who should be in one is a directory problem: check the LDAP synchronization job in symptom 2, run it, and confirm the user’s groups updated. A user in the right group with the wrong permit is the ACL: fix the template or the ACL itself, not the one document.
-
Connectivity: ping the broker, then the projection, then the client config
From the client machine, confirm the connection broker answers and knows the repository:
dmqdocbroker -t <broker-host> -p 1489 -c ping dmqdocbroker -t <broker-host> -p 1489 -c getdocbasemapNo answer is the broker itself (its service, or a firewall change on 1489). An answer that does not list the repository is projection: the Content Server has not registered with that broker, so check the projection_targets in the server config object and the Content Server log for projection errors, and restart the Content Server if its projection has lapsed. A broker that lists the repository while the client still fails is the client: dfc.docbroker.host and dfc.docbroker.port in that client’s dfc.properties, and the certificate it trusts if the broker was recently secured.
03 — Prevention
How do you stop troubleshooting Documentum from the help desk queue?
Every symptom above was visible before the first ticket. Just not to the tools that were watching.
Each of the five failures has the same shape: the infrastructure monitor says healthy, because the server is healthy, while the thing the business depends on — a login under two seconds, a job that completes on schedule, an index that is current, a document the right people can open — has already stopped. Platform SLA is not workflow SLA. The durable fix is to check those outcomes continuously, as a user would, and alert on the first miss. Reveille for OpenText Documentum ships more than 100 pre-configured Documentum tests that cover exactly these chains: Server Sessions – Total Sessions and Active Sessions within a selectable threshold, D2 Login, D2 App Server Check JVM Status, and Check Thread Status for symptom 1; DCTM Jobs Completion against the dm_job table and JMS operating status for symptom 2; xPlore Index Agent Status, Index Pending Count, and Index Failed Count for symptom 3; DQL Query and User Activity for symptom 4; and Test Connection Broker and Test to Logon Repository for symptom 5.
Reveille for OpenText Documentum
Agentless observability for Documentum Content Management and D2 — more than 100 pre-configured tests and over 60 metrics, including the session, job, index agent, and connection broker checks named above. The full catalog is linked above, ungated.
Supporting client estates as an MSP, SI, or ISV? That’s what Reveille SENTRY is built for — multi-tenant observability for the estates you manage.
Frequently asked questions
