A quarantined document does not come back, and by default nothing records that it left
OpenText Content Management scans uploads and downloads through an ICAP server running ClamAV. Infected files land in a quarantine storage provider they cannot leave, and the audit events that would tell you it happened stay switched off until somebody selects them.
Every few years a security review asks the same question, and it is a fair one. Are the documents in the repository scanned for malware? The honest answer at most organisations is that the mail gateway is scanned, the file shares are scanned, the laptops are scanned, and the document repository has never once been part of that conversation. It is the place things go to be kept, and nobody thinks of a warehouse as a route in.
OpenText Content Management, which most people still call Content Server, can scan them. Uploads and downloads both, which is the detail that changes the shape of the answer. Switching it on is a modest piece of configuration on top of a component you have to build and own yourself, and it takes an afternoon.
The two decisions that actually matter are not on the configuration page. What happens to a document that fails the scan, and whether anything anywhere records that it happened. This article is mostly about those two, with the configuration in the middle because you need it.
What actually happens to a file
Nothing goes straight to where it is going. Every item on its way in or out is first written to a protected storage provider, which is a holding area, and scanned there.
From there it goes one of two ways. A clean item moves on to the location it was headed for and the user never notices the detour. An infected one is moved to a quarantine storage provider, and the documentation is direct about what that means: the item cannot be accessed and it cannot be moved.
Two things follow from that description, and both are worth thinking about before anyone enables anything.
The first is that scanning applies in both directions. That is more useful than it sounds, because it is the only answer this feature gives to the question everybody asks next, which is what about the millions of documents already in the repository from before any of this existed. There is no bulk sweep described here. What there is instead is that nothing leaves without being looked at, so the exposure closes on retrieval rather than in one enormous project.
The second is that every upload and every download now makes a round trip through a holding area and a scanner before the user gets anything. That is storage to size and latency to budget on operations that were previously direct. It is not necessarily much, but it is not zero, and it applies to every retrieval rather than to a background job at night.
The part that is not OpenText
Content Management does not scan anything itself. It talks to an ICAP server, and the ICAP server talks to an antivirus engine. ICAP is a standard protocol for handing content to an external service for inspection, so this is a conventional design rather than a proprietary one.
Currently the only supported engine is ClamAV. That single sentence has more project consequence than the rest of the configuration combined, because if the enterprise standard is Defender, Trellix or Sophos, none of them apply here. What you are agreeing to build is a ClamAV deployment behind an ICAP server, and OpenText's documentation politely refers you to the ICAP and ClamAV projects for how to do it.
So the honest scope of this work is not a configuration page. It is a new component in the landscape, sitting in the path of every document upload and download, which somebody now has to patch, monitor, keep signature definitions current on, and place in the availability conversation. Put it in the estimate at the start rather than discovering it in the second week.
Switching it on, in the order it insists upon
The order is not optional, because the configuration validates against it. Both storage providers have to exist before the antivirus page will accept anything.
- Configure the protected storage provider, on the administration page under
Storage Provider Settings>Configure Protected Storage Provider. - Configure the quarantine storage provider, under
Storage Provider Settings>Quarantine Storage Provider. - Then go to
Antivirus Administration>Enable Antivirus Scanning.
That third page behaves in a way that has sent people away thinking the feature has no settings. On first visit it shows one checkbox and nothing else. Select Enable Antivirus, save the page, and the rest of the configuration appears. If you looked at the page before enabling and concluded there was nothing there to configure, that is why.
Once the page opens up there are four things to set:
| Setting | What it is | Default |
|---|---|---|
| Antivirus Integration | The integration type. ICAP is the only choice today | |
| Server Name | Hostname or IP address of the ICAP server | |
| Port | The port that server listens on | 0 |
| Service Name | The ICAP service name | avscan |
The port default deserves a moment. 0 is not a port, it is a placeholder, and the field has to be filled in with the port your ICAP server actually listens on. If nobody chose one deliberately, ICAP's registered port is 1344 and that is very likely what is running.
You do not have to be a system administrator to do any of this. There is a usage privilege, Business Administration > Antivirus Administration, which can be assigned to any user. That is worth knowing, because it lets the people who own malware policy own this setting too, without handing them administrative rights over the entire system.
Test Environment, and what it is really checking
There is a Test Environment button in the Validation area. It is described as optional and it should be treated as mandatory, because it checks four separate things that fail in four different ways:
- that a protected storage provider exists,
- that a quarantine storage provider exists,
- that Content Management can reach the ICAP server you named,
- that the ClamAV engine behind it is running and answering.
Then, when you click Save Changes, it validates a second time, and refuses to save anything if that validation fails. This is unusually good behaviour and worth appreciating: you cannot end up half configured, believing scanning is on when the scanner was never reachable.
What it validates, though, is the state of the world at the moment you press the button. Which brings us to the more interesting question.
The two things the configuration page does not tell you
What happens to a document that fails the scan
It goes to quarantine, where it cannot be accessed or moved. That is unambiguous and, for a genuinely infected file, exactly right.
The case to think about is the other one. Antivirus engines produce false positives, and a signed contract that a scanner mislabels is, from the user's side, simply gone. Somebody should decide in advance who is allowed to look at the quarantine, on what evidence a decision gets made, and what the path back looks like, because the moment this happens for real is not the moment to start designing that process.
The records management angle is sharper still. An item under a retention obligation that lands in quarantine is an item you can neither produce nor dispose of through the normal route. It is worth an explicit conversation with whoever owns retention, before the first false positive rather than after it.
What happens when the ICAP server is unreachable
The documentation covers validation at configuration time. It does not describe how the system behaves at three in the afternoon when ClamAV stops answering, and that behaviour is the single most important thing to establish, because it decides whether you have just made every document retrieval in the organisation dependent on the availability of a scanner.
There are only two possible answers and both are defensible. Either the system refuses the operation, which is safe and turns a scanner outage into a full outage, or it lets the document through unscanned, which keeps people working and quietly puts a hole in the control you just installed. Which one you have is a ten minute test in acceptance: stop the ClamAV service, try to download a document, write down what happened. Do it before go-live, not after.
The audit events are off until somebody turns them on
Two auditing interests come with this feature:
| Event | What it records |
|---|---|
| Antivirus Scan Failed | An item was scanned, failed, and was quarantined. It cannot be accessed or used |
| Antivirus Scan Passed | An item was scanned, passed, and was moved to its destination |
Neither is on by default. They are selected on the Base Settings - Feature Configuration > Event Auditing > Set Auditing Interests page, read back on Query Audit Log, and cleared down on Purge Audit Log.
Antivirus Scan Failed should be switched on the same afternoon scanning is enabled, and it is difficult to construct an argument against it. Without it, a document is quarantined, a user cannot find their file, a support ticket is raised about a missing document, and nothing anywhere connects those three events to each other. It is the same silent failure pattern as an agent that is enabled but never loaded: the system is behaving exactly as designed, and the design includes telling nobody.
A file that was quarantined and never recorded is indistinguishable, six months later, from a file that was never uploaded at all.
— the second week of an investigation that should have taken an afternoon
Antivirus Scan Passed is the one to think about rather than switch on reflexively. It writes an audit row for every clean item in both directions, which on an active repository means one row per download, all day, forever. That is a real answer for a regulated environment that has to demonstrate every retrieval was checked. It is also a fast-growing audit log, and the purge page is a manual one. Count your daily retrievals before you decide, not after.
None of this is difficult, and that is rather the point. Two storage providers, four fields and a checkbox, on top of an ICAP server somebody else has to run. The configuration is the easy half.
The half that decides whether this was worth doing is the set of questions the page does not ask you: who looks in the quarantine, what happens when a clean document ends up there anyway, whether a scanner outage stops the business or silently stops the scanning, and whether anybody will ever be able to prove which documents were checked. Answer those four before you enable anything, and the afternoon of configuration is genuinely all it takes.