Resources · Knowledge catalogue

OpenText estate health: 15 checks worth running

And how to test for each one yourself, without calling anyone.

Every check below exists because it caused a real outage, a failed restore, or a support case that ran for months. None of them need a consultant. They need about half a day, access to your Content Server admin pages and your database, and one honest conversation with whoever keeps the estate running.

Tick a check only if you have verified the answer, not if you believe it to be true. The gap between those two is where most incidents live. If you could not answer a check at all, count it as a red flag. Not knowing is the finding.

Download the printable version Talk to usPrintable PDF to follow

If you only have twenty minutes, run checks 10, 11 and 14.

Section A

The OpenText platform

Why does Content Server get slower over months with no obvious cause?

Very often it is the audit table. Audit data accumulates silently and indefinitely by default, and it degrades query performance across the platform long before anyone connects the two.

How to check: The row count and physical size of your audit table, DAuditNew in most Content Server versions, and whether an audit purge policy is configured and actually running.
Red flag: Tens of millions of rows, a table larger than the rest of the schema combined, or nobody who can tell you when the last purge ran.
Why it matters: It also inflates every backup and every upgrade window. Teams routinely discover this mid-upgrade, when the audit table turns a four-hour outage into a weekend.

Our OpenText notifications stopped arriving. Does it matter?

More than it appears, and the missing email is the least of it.

How to check: The row count of the notification table, Notify, and whether the notification agent is running and draining it.
Red flag: A queue that grows rather than turns over, or notifications users say stopped some time ago that nobody investigated.
Why it matters: A stalled agent leaves a large, permanently churning table dragging on the database. The silence is the bigger problem: something stopped working and nothing told you, which means the same blind spot covers other things too.

Content Server is slow but nothing has changed. Where do we look?

At the indexes on the busiest tables, and specifically at whether the expected ones still exist.

How to check: Index fragmentation, and more importantly the presence of expected indexes on DTree, DVersData, LLAttrData and KIni. Look at execution plans for full table scans on tables with millions of rows.
Red flag: A missing composite index, an index nobody can account for, or full scans where there should be seeks.
Why it matters: This is the most common cause of “it is slow and nobody knows why”. A single missing composite index on a heavily-read configuration table can bring Content Server to its knees while every dashboard stays green, because nothing is technically broken. Restarting helps briefly, which sends teams chasing the wrong cause for months.

Users cannot find recently added documents. What is wrong?

Almost always the search index has drifted from the database.

How to check: When the index was last verified against the database, whether any partition is near its limit, and whether indexing is keeping pace with ingestion.
Red flag: Recent documents not appearing, partitions above roughly eighty percent, or an index rebuild nobody has attempted in over a year because it takes too long.
Why it matters: Search failure is the most visible thing that can happen to a content platform and the least likely to be monitored. Documents that exist but cannot be found are, in a regulated environment, functionally lost.

What happens when an OpenText or OTDS certificate expires?

Depending on which one, either the site stops being trusted or nobody can log in at all.

How to check: List every certificate in the estate with its expiry date. Content Server, OTDS, the reverse proxy, any load balancer, the SAML or identity-provider signing certificates, and anything used for integrations.
Red flag: You cannot produce that list in ten minutes, or anything expiring within ninety days with no owner named against it.
Why it matters: Certificate expiry is the most predictable outage in enterprise IT and one of the most common. The signing certificates catch people out, because they are not on the web-facing list anyone thinks to check, and when they lapse authentication stops entirely.

Why do OpenText logins fail intermittently and then clear on restart?

A classic cause is a firewall silently dropping database connections the connection pool still believes are open.

How to check: The configured OTDS connection pool size, the pool's idle-connection validation setting, and the idle timeout on any firewall between the application tier and the database.
Red flag: A firewall idle timeout shorter than the pool's idle-connection lifetime, with no validation query configured.
Why it matters: The pool hands out dead connections, authentication fails under low load rather than high, and it clears on restart. It presents as a mysterious, unreproducible fault and is genuinely hard to diagnose, because the two systems involved are owned by two different teams who each see nothing wrong on their side.

How do we know if an xECM connector has stopped working?

Usually you do not, until a reconciliation problem surfaces somewhere else.

How to check: For each connector in use, SAP, Salesforce, SuccessFactors, Microsoft 365 or custom, when it last successfully processed a transaction and where its failures are logged.
Red flag: A connector with no monitoring, an error log nobody reads, or a failure queue with items older than a week.
Why it matters: Connectors fail quietly and business users work around them rather than raising tickets. By the time it is reported you have two systems of record that disagree.

How far behind is it safe to let an OpenText version get?

The risk is not the version. It is the compounding.

How to check: Your exact Content Server version and patch level against OpenText's published support lifecycle, and the same for the operating system, Java runtime, application server and database.
Red flag: Any component out of mainstream support, or an upgrade deferred more than twice.
Why it matters: Each deferred upgrade makes the next one larger, riskier and more expensive, until the project is big enough that it never gets approved. Estates do not decide to fall behind. They defer once, then again, and then it is four years.

Why does an upgrade break things that worked fine in test?

Configuration drift, and it is usually undocumented.

How to check: Whether you can produce a record of every configuration change in the last six months, and whether non-production genuinely matches production. For containerised deployments, whether configuration is version-controlled rather than applied by hand.
Red flag: Changes made directly in production with no record, a test environment that is “close enough”, or configuration in a file somebody edits manually.
Why it matters: A value reset by an upgrade, or a container configuration differing by one line between environments, produces a fault that cannot be reproduced anywhere except production. Without a change record you are debugging blind, and the person who made the change may have left.

Section B

The database underneath

Is our OpenText backup actually restorable?

Only if the database and the content store represent the same point in time. This is the most serious item on this page.

How to check: The timestamp of your last database backup and your last content-store backup, then confirm whether they are consistent with each other.
Red flag: The database backed up nightly and the file store weekly. Or a file store on storage that “is replicated” with nobody able to say what that means. Or the two owned by different teams who have never compared notes.
Why it matters: An OpenText estate is a database and a content store that must be restored together. If they are inconsistent you will restore to a state where the database references documents the file store does not have, or holds documents the database has forgotten. Both are data loss, and you will not find out until the day you need the restore. Very few organisations have checked this, and most assume someone else has.

Our backups report success. Is that enough?

No. A backup you have not restored is a hypothesis.

How to check: The date of the last full restore actually performed to a working system. Not a backup job reporting success. An actual restore.
Red flag: Never, more than twelve months ago, or “we restored a single file once”.
Why it matters: Recovery takes longer than anyone estimates, and the failure is usually procedural rather than technical. A missing encryption key, an undocumented step, a dependency nobody recorded. Find that out on a Tuesday afternoon, not during an incident.

What database maintenance does an OpenText estate actually need?

More specific maintenance than a generic plan provides, because OpenText workloads have characteristic query patterns.

How to check: Whether statistics are gathered on a schedule appropriate to your churn, the growth rate of your largest tables, and remaining headroom in tablespaces or filegroups, temp space and transaction log or redo space.
Red flag: Stale statistics on high-churn tables, under six months of headroom at current growth, or nobody who can tell you the growth rate at all.
Why it matters: Default maintenance plans are frequently tuned for the wrong thing here, and the symptom appears as application slowness rather than as a database alert, so it gets investigated in the wrong place.

Our database has failover. Does that mean OpenText survives it?

Not necessarily, and this is the half that rarely gets tested.

How to check: If you run Always On, Failover Cluster, RAC or Data Guard, when failover was last tested end to end including the application tier reconnecting.
Red flag: Database failover tested but application reconnection not. Replication lag not monitored. Or the test was run by someone who has since left.
Why it matters: Database failover that works perfectly while the application tier sits holding dead connections is not high availability.

Section C

The people and the process

What happens if our only OpenText administrator leaves?

Test it before you find out.

How to check

Name the person who understands the estate most deeply, then ask someone else to describe the correct restart order for the full stack, where the customisations live, and which settings reset after an upgrade.

Red flag

Only one person can answer, or the second person's answer differs from the first.

Why it matters

Specialist OpenText knowledge is scarce, slow to replace and mostly undocumented, because it lives in the head of someone who has been solving the same estate's problems for years. The exposure is not only that they might leave. It is that the estate cannot be safely changed while they are on holiday.

If this is already happening, the handover window closes on their last day, and capturing what they know is more urgent than backfilling the role. Interim cover exists for exactly this.

What should we actually monitor on an OpenText estate?

Something that behaves like a user, not just something that checks the service is running.

How to check: What your monitoring actually tests, then ask whether it would catch a case where every service is running, every port responds, and users still cannot retrieve a document.
Red flag: Monitoring limited to host and port availability. Nobody alerted outside working hours. Alerts going to a distribution list rather than a named person on a rota.
Why it matters: Most OpenText incidents do not look like an outage. The platform is up, the database is up, and something in between has failed in a way only a real transaction reveals. Synthetic monitoring that logs in and fetches a document is the only check that reflects what your users experience, and it is rarely in place.

Scoring

Count your red flags

Count your red flags: what your number of red flags means
Red flags	What it means
0 to 2	A well-run estate. Keep the documentation current as people change.
3 to 5	Normal for a busy team. Nothing urgent, but the gaps compound. Close the two highest-consequence ones this quarter.
6 to 9	The estate is running on the knowledge of individuals rather than on process. The most common result, and the point at which one departure or one upgrade becomes a serious problem.
10 or more	Treat continuity as a project rather than a task. Start with check 10, then 11, then 14, in that order.

If you could not answer a check at all, count it as a red flag. Not knowing is the finding.

Where to start

The three checks that cannot wait.

Check 10.

Confirm your database and content store can be restored to a consistent point in time. Not assumed. Confirmed.

Go to check 10

Check 11.

Rehearse a restore before you need one.

Go to check 11

Check 14.

Write down what only one person knows, while they still work there.

Go to check 14

Everything else on this page can wait. These three are your priority.

Closing

Found something you cannot answer?

That is the point of the exercise, and it is a good outcome rather than a bad one. If you want a second opinion on what you turned up, that conversation is free, with no obligation on your side.

This page is written to be run without us. Use it, copy it, circulate it internally.

Talk to us